Curl is C - <AUTHOR> https://daniel.haxx.se/blog/2017/03/27/curl-is-c/ <comment><USER2> I have no problem with Curl being written in C (I'll take battle-tested C over experimental Rust) but this point seemed odd to me:

>C is not the primary reason for our past vulnerabilities

>There. The simple fact is that most of our past vulnerabilities happened because of logical mistakes in the code. Logical mistakes that aren't really language bound and they would not be fixed simply by changing language.

So I looked at [https://curl.haxx.se/docs/security.html](https://curl.haxx.se/docs/security.html)

#61 -> uninitialized random : libcurl's (new) internal function that returns a good 32bit random value was implemented poorly and overwrote the pointer instead of writing the value into the buffer the pointer pointed to.

#60 -> printf floating point buffer overflow

#57 -> cookie injection for other servers : The issue pertains to the function that loads cookies into memory, which reads the specified file into a fixed- size buffer in a line-by-line manner using the fgets() function. If an invocation of fgets() cannot read the whole line into the destination buffer due to it being too small, it truncates the output

This one is arguably not really a failure of C itself, but I'd argue that Rust encourages a more robust error handling through its Options and Results when C tends to abuse "-1" and NULL return types that need careful checking and can't usually be enforced by the compiler.

#55 -> OOB write via unchecked multiplication

Rust has checked multiplication enabled by default in debug builds, and regardless of that the OOB wouldn't be possible.

#54 -> Double free in curl_maprintf

#53 -> Double free in krb5 code

#52 -> glob parser write/read out of bound

And I'll stop here, so far 7 out of 11 vulnerabilities would probably have been avoided with a safer language. Looks like the _vast majority_ of these issues wouldn't have been possible in safe Rust.

<comment><USER3> > Of course that leaves a share of problems that could've been avoided if we > used another language. Buffer overflows, double frees and out of boundary > reads etc, but the bulk of our security problems has not happened due to > curl being written in C.

He addressed all of those points in the second short paragraph. None of those are C vulnerabilities, they were mistakes made on the part of the developers, not the language. Avoidance of problems in a safer language doesn't mean when things happen, it's the language's fault.

<comment><USER4> These are surely C vulnerabilities and contradict the statement regarding zero policy static analysis errors.

#55 -> OOB write via unchecked multiplication

#54 -> Double free in curl_maprintf

#53 -> Double free in krb5 code

#52 -> glob parser write/read out of bound

<comment><USER5> Double free is not necessary a C issue, but it can be also a program logic issue - I expect to have an object, but it's already deleted. So it's one of

1\. object should not exist and the second free is incorrect 2\. object should exist and the first free is incorrect 3\. object existance is uncertain and the second free must somehow check that

Although I can double-free only in unsafe languages, the wrong logic behind it can be the same in safe languages. It just have different consequences.

<comment><USER6> Of course it is a C issue, in the same sense that ALL logic errors are in the case you describe -- so either C issues do not exist or you did not manage to find the correct definition: for ex OOB access is caused by faulty program logic, and the consequences are dramatic in unsafe languages. That is an issue of the language, despite you being able to compute OOB indexes in any language. Same thing for double free; the language issue is that the result is catastrophic, not that you can write for ex faulty logic attempting a liberation too early, or an extra one. (Because in safe languages, the result is not _as_ catastrophic as in unsafe languages).

That is the _whole_ concept of safety.

<comment><USER5> Let's take some safe language, e.g. c#

1\. object should not exist and the second free is incorrect

In C# I can have to variables pointing to the same object, I null only one of them. The second should be nulled too, but it's not. That's a logic error. So in C# I end up with some object that should not be there, but it is. Which is better - doube-free or undestroyed object - depends on use case.

<comment><USER4> The _big_ difference that you are overlooking is that double free leads to memory corruption, with undefined behavior of program execution.

It can crash right away, in a few seconds, minutes, hours later, or never and just keep generating corrupt data.

Having a reference that the GC doesn't collect doesn't lead to memory corruption, just more being used than it should be.

<comment><USER5> > Having a reference that the GC doesn't collect

Using such object is/can be as dangerous.

In fact I find double-free safer because it usually crashes (and in my code I do checks so it almost certainly crashes), while in C# I can happily use such object without knowing it. But as I said, it depends on specific use case.

<comment><USER7> > In fact I find double-free safer because it usually crashes (and in my code > I do checks so it almost certainly crashes)

You don't know what an undefined behavior is, do you ? You cannot be sure it crashes since the compiler is allowed to do anything with the assumption it doesn't happen. It's absolutely legit for the compiler to remove all the code you added to check a double-free didn't happen because it is assuming that's dead code.

See this post[1] from the LLVM blog which explains why you can't expect anything when you're triggering an UB.

[1]: [http://blog.llvm.org/2011/05/what-every-c-programmer- should-...](http://blog.llvm.org/2011/05/what-every-c-programmer-should- know_14.html?m=1)

<comment><USER5> I know very well what UB is and I bet there is not a single big program which does not have undefined behaviour. I even rely on UB sometimes, because with well defined set of compilers and systems, it's in reality well defined.

I was talking in general about "unsafe" languages. I use c++ in my projects and use custom allocators everywhere, so there is no problem with UB there. The custom allocators also do the checking against double-free.

<comment><USER6> What do you mean by checking against double-free? Either you pay a high runtime cost, or use unconventional (and somehow impractical in C++) means (e.g. fancy pointers everywhere with a serial number in them), or you can't check reliably. Standard allocators just don't check reliably, and thus do not provide sufficient safety.

Anyway, double-free was only an example. The point is that a language can, or not, provide safety _by itself_. Not _just_ allow you to create you own enriched subset that is safer than the base language (because you often are interested in safety of 3rd party components not written in your dialect and local idioms of the language)

In the case of C and C++, they are full of UB, and in the _general case_ UB means you are dead. I find that _extremely_ unfortunate, but this is the reality I have to deal with, so I don't pretend it does not exist...

<comment><USER5> > What do you mean by checking against double-free?

I pay small runtime cost for the check by having guard values around every allocation. At first I wanted to enable it only in debug builds, but I am too lazy to disable it in release builds, so it's there too. Anyway the overhead is small and I do not allocate often during runtime.

> Anyway, double-free was only an example. The point is that a language can, > or not, provide safety by itself.

I can write safe code in modern C++ (and probably in C) and I can write unsafe code in e.g. Rust, only difference is which mode is default for the language. On the other hand I have to be prepared to pay the performance (or other) price for safe code.

> In the case of C and C++, they are full of UB, and in the general case UB > means you are dead.

I doubt there is a big C or C++ program without UB, does that mean they are all dead? I do not think so.

> I find that extremely unfortunate, but this is the reality I have to deal > with, so I don't pretend it does not exist...

I do not like UB in C++ too, but mostly because it does not make sense on platforms I use. On the other hand I can understand that the language can not make such platform-specific assumptions. I can pretend UB does not exist with some restrictions. UB in reality does not mean that the compiler randomly do whatever he wants, it do whatever he wants but consistently. But as I said it twice, it depends on use case. Am I writing for SpaceX or some medical instruments? Probably not a good idead to ignore UB. Am I making writing a new Unreal Engine? Probably not a good idea to worry much about UB, since I would never finish.

<comment><USER6> > UB in reality does not mean that the compiler randomly do whatever he wants, > it do whatever he wants but consistently.

There is nothing consistently consistent about UB. The exact same compiler version can one day transform one particular UB to something, the other day to something else because you changed an unrelated line of code 10 lines under or above, and the day after tomorrow if you change your compiler version or even just any compile option, you get yet another result even when your source code did not changed at all.

EDIT: and I certainly do find _extremely_ unfortunate that compiler authors are choosing to do that to us poor programmers, and that they mostly dropped the other saner interpretation expressively allowed by the standard and practiced by "everybody" 10 years ago; that UB can also be for non portable but well-defined constructs. But, well, compiler authors did that, so let's live with it now.

<comment><USER5> > There is nothing consistently consistent about UB.

Yet, for years I am memmove-ing objects which should not be memmoved. Or using unions the way they should not be used.

> and that they mostly dropped the other saner interpretation expressively > allowed by the standard and practiced by "everybody" 10 years ago

Do you have any example?

> that UB can also be for non portable but well-defined constructs.

Do you mean instead of signed integer overflow being UB it should be defined as 2 complement or something like that?

<comment><USER6> > Yet, for years I am memmove-ing objects which should not be memmoved. Or > using unions the way they should not be used.

There can be two cases:

A. you rely on additional guarantee of one (or several) of the language implementation you are using (ex: gcc, clang). Each compiler usually has some. They are explicitly documented, otherwise they do not exist.

B. you rely on undocumented internal details of your compiler implementation, that are subject to change at any time, and just have happened to not have changed for several years.

> Do you have any example?

I'm not sure that compiler did "far" (not just intra-basic-block instruction scheduling) time-traveling constraint propagation on UB 10 or 15 years ago. For sure, some of them do now. This means you should better use fno-delete- null-pointer-checks and all its friends, because that might very well save you completely in practice from some technically UB but not well known by your ordinary programmer colleague - so likely to appear in lots of non-trivial code bases.

Simpler example: behavior of signed integer overflow. (Very?) old compilers simply translated to the most natural thing the target ISA did, so in practice you got 2s complement behavior in tons of cases and tons of programs started to rely on that. You just can't rely on that so widely today without special care.

More concerning is the specification of << and >> operators. On virtually all platforms they should map to shifting instructions that interpret unsigned int a << 32 as either 0 or a (and same thing for a>>0), and so regardless of the behavior (a<<b) | (a>>(32-b)) should do a ROL op. Unfortunately, mainly because some processors do one behavior and others do the other one (for a single shift), the standard specified it as UB. Now in the standard spirit, UB _can_ be the sign something that is non-portable but perfectly well-defined. Unfortunately now that compiler authors have collectively all "lost" (or voluntarily burned) that memo, and are actively trying to trap other programmers and kill all their users, either it is already handled as all other UB in their logic (=> nasal daemons) or it is only an event waiting to happen...

Maybe a last example: out-of-bound object access was expected to reach whatever piece of memory is at the position of the intuitively computed address, in the classical C age. This is not the case anymore. Out-of-bound object access now carry the risk of nasal-daemons invocation, regardless of what you know about your hardware.

Other modern features of compilers also have an impact. People used to assume all kind of safe properties at TU boundaries. Those where never specified in the standard, and they have been dropped through the window with WPO. It is likely that some code-bases have "become" incorrect (become even in practice, given they always have been in theory with the most risky interpretations of the standard, that compiler authors are now unfortunately using)

> Do you mean instead of signed integer overflow being UB it should be defined > as 2 complement or something like that?

Maybe (or at least implementation specified). I could be mistaking, but I do not expect even 50% of C/C++ programmers knowing that signed overflow is UB, and what it means precisely on modern implementations. I would even be positively surprised if 20% of them know about that.

And before anybody through them at me:

* I'm not buying the performance argument at least for C, because the original intent of UB certainly was not to be yielded this way, but merely to specify the lowest common denominator of various processors -- its insanely idiotic to not be able to express a ROL today because of that turn of events and the modern brain-fucked interpretation of compiler authors -- and more importantly because I happen to know how modern processors work, and I do not expect stronger and safer guarantees to notably slow down anything)

* I'm not buying the "specify the language you want yourself or shut up" argument either, for two at least reasons: \- I also have an opinion about safety features in other aspects of my life, yet I'm not an expert in those area (e.g. seat belt). I _am_ an expert in CS/C/C++ programming/System Programming/etc... and I'm a huge user of compilers, in some case in areas where it can have an impact on people health. Given that perspective, I think any argument to just specify my own language or write my own compiler would just be plain stupid. I expect people actually doing that for a living (or as a main voluntary contributor, etc..) to use their brain and think of the risks they impose on everybody with their idiotic interpretations, because regardless of they want it or I want it or not, C and C++ _will_ continue to be used in critical systems. \- The C spec is actually kind of fine, although now that compiler author have proven they can't be trusted with it, I admit it should be fixed at the source. But would have them be more reasonable, the C spec would have been continued to be interpreted like in the classical days, and most UB would merely have been implementation defined or "quasi-implementation defined" (in some cases by defining all kind of details like a typical linear memory map, crashing the program in case of access to unmapped are, etc...) in the sense you are thinking of (mostly deterministic -- at least way more than it unfortunately is today). The current C spec _do allow_ that and _my_ argument would be that doing otherwise (except if the performance price is extremely highly unbearable, but the classical implementations have proven it is not!). So I don't even need to write an other less dangerous spec, they should just stop to write dangerous compilers...

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I'm kind of torn on this.

On the one hand, Curl is a great piece of software with a better security record than most, the engineering choices it's made thus far have served it just fine, and its developers quite reasonably view rewriting it as risky and unnecessary.

On the other hand, the state of internet security is really terrible, and the only way it'll ever get fixed is if we somehow get to the point where writing networking code in a non-memory-safe language is considered professional malpractice. Because it should be; reliably not introducing memory corruption bugs without a compiler checking your work is a higher standard than programmers can realistically be held to, and in networking code such bugs often have immediate and dramatic security consequences. We need to somehow create a culture where serious programmers don't try to do this, the same way serious programmers don't write in BASIC or use tarball backups as version control. That so much existing high-profile networking software is written in C makes this a lot harder, because everyone thinks "well all those projects do it so it must be okay".

<comment><USER9> > the only way it'll ever get fixed is if we somehow get to the point where > writing networking code in a non-memory-safe language is considered > professional malpractice.

So using Linux, Windows, BSD or MacOS servers are malpractice? I think you might have over stated your case. So are you waiting for a memory safe Herd re-write? A memory safe any OS will be decades away if someone wanted to start tackling it now.

<comment><USER4> Microsoft does research how to improve security at OS level and sometimes those efforts do end up on Windows.

Latest examples, Windows 10 secure kernel and Device Driver protection.

[https://myignite.microsoft.com/sessions/36925](https://myignite.microsoft.com/sessions/36925)

Or the new Windows USB stack, written in the P language.

[https://github.com/p-org/P](https://github.com/p-org/P)

UNIXes, not so much beyond patching C exploits.

<comment><USER10> And the last windows 7 update black screened my pc and left me in limbo till I was able to restore. What exactly is your point? Windows is not a standard to be held higher than..well anything.

<comment><USER11> The parent commenter used Windows 10 as an example and you used Windows...7. His point, which is that Microsoft actively researches and implements OS-level security improvements, hasn't been rebutted by your statement about Windows 7.

Windows 7 was released in _2009_. There are substantial proactive improvements that Microsoft cannot feasibly backport to older OS versions even if they're still within the support period, and the corporate culture was simply different when Windows 7 was released.

<comment><USER12> Counter-point: Windows 10 updates locked up 2 of my machines - Microsoft has a tough time implementing _most_ things properly...

</comment></comment></comment></comment></comment></comment><comment><USER13> While this doesn't so much apply to libcurl (but see below), there is a third alternative to "write everything in C" or "write everything in <some other safer language>". That is: _use a safer language to generate C code_.

End users, even those compiling from source, will still only need a C compiler. Only developers need to install the safer language (even Curl developers must install valgrind to run the full tests).

Where can you use generated code?

\- For non-C language bindings (this could apply to the Curl project, but libcurl is a bit unusual in that it doesn't include other bindings, they are supplied by third parties).

\- To describe the API and generate header files, function prototypes, and wrappers.

\- To enforce type checking on API parameters (eg. all the CURL_EASY_... options could be described in the generator and then that can be turned into some kind of type checking code).

\- Any other time you want a single source of truth in your codebase.

We use a generator (written in OCaml, generating mostly C) successfully in two projects: [https://github.com/libguestfs/libguestfs/tree/master/generat...](https://github.com/libguestfs/libguestfs/tree/master/generator) [https://github.com/libguestfs/hivex/tree/master/generator](https://github.com/libguestfs/hivex/tree/master/generator)

<comment><USER14> > generate C code.

Programmatically generating C code not without problems. How can you prove that the C you're generating is free from problems solved by the safer language? Cloudbleed came from computer generated C code: [https://blog.cloudflare.com/incident-report-on-memory- leak-c...](https://blog.cloudflare.com/incident-report-on-memory-leak-caused- by-cloudflare-parser-bug/).

<comment><USER15> No, it didn't.

See quote from the author of Ragel in the comments:

 _There is no mistake in ragel generated code. What happened was that you turned on EOF actions without appropriate testing. The original author most certainly never intended for that. He /She would have known it would require extensive testing. Legacy code needs to be tested heavily after changes. It should have been left alone.

PLEASE PLEASE PLEASE take some time to ensure the media doesn't print things like this. It's going to destroy me. You guys have most certainly benefitted from my hard work over the years. Please don't kill my reputation!_

<comment><USER16> Well, the general point still applies. The bug occurred using code that was written in a safe language and compiled to C. It's just that there are multiple ways for that to go wrong. The generator _could_ have had a bug -- it's software, so it almost certainly does. Or, as in this case, the user didn't use it correctly. Either way, the idea that you can write code in a safe language and compile to C to eliminate the type of bugs that C allows isn't true.

Are such errors less likely? Possibly so, but they're not categorically eliminated. It becomes a risk assessment exercise rather than a simple thing that everyone should do. Note that it also opens the door to Java-style problems, where once the generator becomes ubiquitous, it becomes the most valuable target for exploit-hunting because a vulnerability in the generator gets the keys to _all_ the houses.

<comment><USER17> You are arguing that no language X is safer than writing program manually in Y when program in X is compiled to Y. Because compiler from X to Y may have bugs.

Therefore no code written in Rust (X) executed on x86 CPU (Y) is safer than manually written x86 assemby, because Rust compiler (and LLVM) may have errors.

And well, we can actually go deeper. There is CPU frontend that is generating micro code, which may have bugs. There is also CPU backend which is executing micro code, which also may have bugs. All in all there is no hope in programming. There might be bugs everywhere so you can never be sure what your program does.

<comment><USER16> That's not what I'm saying. I'm saying "rewrite it in Rust (or whatever)" isn't some silver bullet that fixes security problems. It's always about assessing risk -- both risk of security issues as well as risk of upsetting your users, etc. Basically exactly what the article says.

<comment><USER17> > Either way, the idea that you can write code in a safe language and compile > to C to eliminate the type of bugs that C allows isn't true.

Is a bit different statement than:

> I'm saying "rewrite it in Rust (or whatever)" isn't some silver bullet that > fixes security problems.

The first one is wrong, the second one is true.

Using a higher level language rules out some classes of programming errors which are possible in lower level languages. The fact that compilers have bugs does little to diminish those gains.

Semantics of Haskell does not allow to express program that generates double free [0]. Perhaps one of the compilers will compile some Haskell code to binary that frees memory twice. However, this bug in compiler is far more less likely that a programmer making this mistake in C. Whats more when this bug in compiler is detected and fixed. The problem can be fixed in all affected code bases without need to change the original source code. Thus chances of bugs are lower.

Nobody really argues that Rust (or OCaml, or Haskell, or whatever) is a silver bullet, i.e. solution to all problems that will miraculously make programmers produce no bugs at all. Obviously we will have software bugs even with most restrictive languages. No amount of formal proofs will save us form misunderstanding specifications or making typos. And then again we will also have bugs in implementation of those high level abstractions.

And for the record I am really annoyed with movement to rewrite everything in Rust.

[0] Yes, you can call free through FFI with whatever arguments you like, as many times as you like. But for sake of brevity let's assume this is not how you write your everyday Haskell.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> Not only is curl based on C, but so are operating systems, IP stacks and network software, drivers, databases, Unix userland tools, web servers, mail servers, parts of web browsers and other network clients, language runtimes and libs of higher-level languages, compilers and almost all other infrastructure software we use daily.

I know there's a sentiment here on HN against C (as evidenced by bitter comments whenever a new project dares to choose C) but I wish there'd be a more constructive approach, acknowledging the issue isn't so much new software but the large collection of existing (mostly F/OSS) software not going to be rewritten in eg. Rust or some (lets face it) esoteric/niche FP language. Even for new projects, the choice of programming language isn't clear at all if you value integration and maintainability aspects.

<comment><USER19> > I know there's a sentiment here on HN against C

I think there's two major against-C groups: those of us who have worked with C for decades and those who never worked with it. I'll try and speak for those of us who've used it for decades. The popular high-level languages that have arrived since ~1995 (Java, Python, JS, C# and friends) are excellent productivity increases. In general, they sacrifice memory and performance in favor of robustness and security. For enormous software problem domains, we just don't need C's complexity or error-proneness.

Until Rust, there's been very close to zero serious competitors for C if I wanted to write a bootloader, OS, or ISR. Not even C++ could do those (without being extremely creative on how it's built/used). The ~post-2000 languages (golang, swift, D etc) can't do that (perhaps D's an exception but it wasn't an initial goal AFAICT). This is huge, IMO.

We've groaned and grumbled about how hard it is to parse C/C++ code for decades. This is a big deal for tooling. Because of the language's design, even if you use something "simple" like libclang to parse your code, you still have to reproduce the entire build context just to sanely make an AST. All of those other new languages above probably address this problem but also add all kinds of other stuff which we can't have for specialized problem domains (realtime/low-latency requirements, OSs, etc).

> collection of ... software not going to be rewritten in eg. Rust or some > (lets face it) esoteric/niche FP language

IMO it's not appropriate to lump Rust in with "nice FP language"s. And don't look now but lots of stuff _is_ being rewritten in Rust. Fundamental this-is- the-OS-at-its-root stuff: coreutils [1], "libc" [2], kernels [3], browser engines [4].

[1] [https://github.com/uutils/coreutils](https://github.com/uutils/coreutils)

[2] [https://github.com/japaric/steed](https://github.com/japaric/steed)

[3] [https://github.com/redox-os](https://github.com/redox-os)

[4] [https://github.com/servo/servo](https://github.com/servo/servo)

<comment><USER20> Could you expand on why you think Rust is a serious C competitor for OS/ISR/bootloaders but not C++? This statement intrigued me.

I thought C++ had naked functions and all the things you need to write an OS.

<comment><USER21> Not wyldfire, and I think that claim is a mischaracterization, but the main obstacle to using C++ in the kernel is that some of its language features require runtime support (new/delete, globals/statics with constructors, exceptions).

You can of course just ignore those when writing kernel code- they get ignored in application code much of the time! But I suppose at that point it could be argued that you're just writing C with a C++ compiler?

<comment><USER22> [https://en.wikipedia.org/wiki/Symbian](https://en.wikipedia.org/wiki/Symbian)

<comment><USER4> Add BeOS, OS X drivers (IO Kit) and OS / 400 after they started rewriting the PL/M code, to that list.

</comment></comment></comment></comment></comment></comment><comment><USER23> Well put.

Didn't know that curl was stuck back on C89, that's really optimizing for portability.

If anyone is confused by the "curl sits in the boat" section header, that's basically a Swedish idiom being translated straight to English. That rarely works, of course, and I'm sure Daniel knows this. :)

The closest English analog would be "curl doesn't rock the boat", I think the two expressions are equivalent (if you sit, you don't rock the boat).

<comment><USER24> I didn't know "sit in the boat was a thing", but I liked it.

"Sit in boat" is a positive expression of the stability benefits.

</comment></comment><comment><USER25> The 7th point: "curl sits in the boat"

        In the curl project we're deliberately conservative and
        we stick to old standards, to remain a viable and reliable
        library for everyone. Right now and for the foreseeable
        future. Things that worked in curl 15 years ago still work
        like that today. The same way. Users can rely on curl. We
        stick around. We don't knee-jerk react to modern trends.
        We sit still in the boat. We don't rock it.

I see a lot of inertia in there. While it's a great record to maintain 15-year consistency but in the era of every changing InfoSec outlook, it could be a legacy and baggage if the authors resist to change. One thing we know for sure is that human will make mistakes, no matter how skillful you are. In the context of writing a fundamental piece of software with an unsafe programming language, that means we are guarantee to have memory-safety induced CVE bugs in curl in the future.

Some of other points that the author raised are valid too. If there is a trade-off that we can have a safer piece of fundamental software by almost eliminating a whole category of memory safety related bugs, and with the downside of less compatibility with legacy systems, more dependencies etc., perhaps we should consider it? I believe the tradeoff is well worthy in the long run and option is ripe for explore.

<comment><USER26> How is the author resistant to change? He specifically said new code should be written in a language that meets the priorities for that code. He specifically said someone has or would write a competitor to curl in Rust or some other safer language and that a good one will take off. He welcomed that.

What he doesn't welcome is rewriting something that's had those bugs and the types of logic bugs not related to the language already worked out. There's a saying about a baby and bathwater.

Not everything is a dichotomy, and you shouldn't be reading the article as if the author is against newer languages. He specifically says that given a fresh start with the availability of these languages he might use something besides C. Carefully weighing options is wise. Throwing away years of actual progress for the appearance of quick progress is foolish.

<comment><USER25> > How is the author resistant to change?

I specially quoted the section head "curl sits in the boat" and the entire section ends with "We sit still in the boat. We don't rock it". Now read it again, and then tell me if that's welcoming changes or resisting changes.

> He specifically said someone has or would write a competitor to curl in Rust > or some other safer language and that a good one will take off. He welcomed > that.

Sure there might already be some alternatives out there. But those are not curl, they are at most forks.

> He specifically says that given a fresh start with the availability of these > languages he might use something besides C.

Nope, he used the word "Maybe. Maybe not." Might is a stronger word.

<comment><USER26> Having no plans to change curl within itself is not a resistance to change in general.

Not everything is a dichotomy. One doesn't have to be for all change or against all change. One can choose which things need to change.

<comment><USER27> I see "we don't rock the boat" as completely synonymous with "I am resistant to change".

(Note that I suspect you think that I or the original poster are suggesting that he's resistant to _all_ change, not just change within curl. I don't believe he's resistant to all change, but I do believe he's resistant to change within curl, which is what we're talking about here.)

<comment><USER26> He's not resistant to change in the problem space. He's resistant to very particular types of change in one very particular codebase, and for very sound reasons.

He doesn't want to break the ecosystem around curl, which is huge, while getting back to feature parity and compatibility during a full rewrite. Something that comes along and replaces curl externally needn't be completely compatible and therefore is freer to leverage their new, fresh start much more fully. He welcomes a competitor, which means even a possible complete replacement. That's not a resistance to change. That's being very judicious about what one changes and why.

<comment><USER25> > He doesn't want to break the ecosystem around curl, which is huge, while > getting back to feature parity and compatibility during a full rewrite

Very good point! However, rewrite doesn't have to break the existing ecosystem and it can happen in a parallel track right? (curl has had 1.5k contributors so far so the community should have enough support to maintain existing codebase while developing new version on a new programming language hypothetically speaking.)

In fact, I would argue that the "it works now and has been working for 15 years so we don't rock the boat" attitude is negatively impacting the curl ecosystem in the long run. I'm a python developer, a good example I can give you to support my view is the python 2.x to py3k transition (If the "better unicode support" is analogous to "memory safety bug avoidance").

[1]: [https://github.com/curl/curl/blob/master/docs/THANKS](https://github.com/curl/curl/blob/master/docs/THANKS)

<comment><USER26> Python 2 to Python 3 was basically world-breaking for many projects. Most every non-trivial piece of code needed to be modified to work with 3. Many people maintain older code on 2 to this day even with newer code being written on 3 by the same people.

Is that what you're wanting for curl?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> It's extremely simple. If you think Curl would be better in another language then port it, release your alternative, and maintain it for a long time.

Even if your language (Rust, Erlang, LISP, Go) is "better", it's still a minimal part of the equation. A maintainer is what makes the tool. It's hard work to decide which PRs to accept (and worse yet, reject), to backport fixes to platforms for which you can't get a reliable contributor, coordinating fundraising/donations, keeping up with evolving standards...

Anyway. Thank you, thank you, thank you Daniel Stenberg. Use whatever damn language you want.

<comment><USER29> > _Use whatever damn language you want._

On the other hand, if he didn't want his justifications for that choice examined by the world, he wouldn't have aired them, right?

> _If you think Curl would be better in another language then port it, release > your alternative, and maintain it for a long time._

That's out there; some languages have URL downloading objects that are not based on Curl.

E.g. Edi Weitz's Drakma client library for Common Lisp doesn't seem to be using Curl as far as I can see.

[http://weitz.de/drakma/](http://weitz.de/drakma/)

<comment><USER28> I wouldn't presume to speak for Daniel, but I got the feeling that he just wanted to publish this to point people to rather than send the same canned response to inquiries about porting to Rust et al.

Drakma sounds great. Tone is tough to get right online. I don't like people doing drive-by suggestions like "you should rewrite X in Y". But if people are really willing to roll up their sleeves, write the tool (in any language) and keep it going for the long haul, I applaud them. I just have great respect and empathy for project maintainers, I think some don't appreciate what a huge PITA it is to BDFL a successful project.

</comment></comment></comment><comment><USER30> > A library in another language will add that language (and compiler, and > debugger and whatever dependencies a libcurl written in that language would > need) as a new dependency to a large amount of projects that are themselves > written in C or C++ today. Those projects would in many cases downright > ignore and reject projects written in "an alternative language".

Why would I be vendoring my own copy of libcurl in my project? Who does? This is how I (or rather, the FFI bindings my language's runtime uses) consume libcurl:

        dlopen("libcurl.so")

I rely on a binary libcurl _package_. The binary shared-object file in that package needed a toolchain to build it, but I don't need said toolchain to consume it. That would still be true even if the toolchain required for compiling was C++ or Rust or Go or whatever instead of C, because either the languages themselves, or the projects, ensure that the shared-object files they ship export a C-compatible ABI.

An example of a project that works the way I'm talking about: LLVM. LLVM is written in C++, but exports C symbols, and therefore "looks like" C to any FFI logic that cares about such things. LLVM is a rather heavyweight thing to compile, but I can use it just fine in my own code without even having a C++ compiler on my machine.

(And an example of a project that _doesn 't_ work this way: QT. QT has no C-compatible ABI, so even though it's nominally extremely portable, many projects can't or won't link QT. QT fits the author's argument a lot better than an alternate-language libcurl would.)

</comment><comment><USER31> Agreed 100%. Definitely going to be trotting this article out next time I see someone blindly arguing for rewriting xyz in Rust.

I particularly like the mention of portability. No other language comes even _remotely_ close to the portability of C. What other language runs on Linux, NT, BSD, Minix, Mach, VAX, Solaris, plan9, Hurd, eight dozen other platforms, freestanding kernels, and nearly every architecture ever made?

<comment><USER32> I mean, sure, and if you have users running VAX or the Hurd, that matters. But it turns out that most of us use one of Linux, NT or OS X. And even if you add BSD and Solaris (and a few other Unixes) you can still find languages without C's known problems that cover 100% of users. "But embedded." Embedded can maintain their own software, they do all the time. How long are we going to insist that end users run software that cannot be secure because of the lowest common denominator of programming languages?

<comment><USER31> I think this is a flawed mindset for a number of reasons.

First, I'd rather appeal to every user than most users. That one user I didn't have to appeal to is going to be a much more faithful and grateful user than the "normal" ones. Most of my software work is open source (remember this context is a discussion about curl), and this encourages active collaboration with users with niche situations. If I choose technologies that make using my software attainable for these people, odds are they aren't going to stop at just porting it to their platform.

Limiting your platforms to Linux, OSX, and NT also stifles innovation. These platforms are all deeply flawed. Their popularity isn't due to having the best design, but rather to having a _good enough_ design and being entrenched. They're old platforms, we've learned a lot since they were started. New or niche platforms bring a lot of value to the table. The BSDs are a great example, as it's the best suited platform for a wide variety of applications.

All a new platform has to do to be able to run nearly all general purpose software is port a C compiler. Not even that - they just need a cross compiler. This is a great thing, IMO.

>Embedded can maintain their own software, they do all the time

This is a pretty silly argument. Most embedded developers don't ship their own implementation of HTTP, they ship curl!

<comment><USER32> > Their popularity isn't due to having the best design, but rather to having a > _good enough_ design and being entrenched. They're old platforms, we've > learned a lot since they were started.

I think one could say the same thing about C's popularity as a language.

<comment><USER31> I disagree. I think C is extremely well designed, but there are unfixable shortcomings to this design. Choosing it is a tradeoff.

<comment><USER33> C was well-designed for its time, but "extremely" well-designed is a stretch given the much better designs that came immediately before (ALGOL 60 and 68, Pascal, Scheme) or after (Ada, Modula, ML) it. C was optimized to be fast to implement (and won out for that reason — "worse is better," and because UNIX was the first usable OS written in a high-level language), not for the best practices in safety or even performance, even as understood at the time.

<comment><USER31> I'm not talking about pre-ANSI C. Compare C89 to those languages and, in my opinion, C comes out on top.

<comment><USER33> I'd really disagree. All those languages are both safer and more expressive (if more verbose in the case of those with Pascal-like syntax) than any version of C, and, except in the case of ML, Scheme and ALGOL 68 with the optional garbage collection, there's no reason they couldn't be as fast or faster than C. Their main fault was simply in being too ahead of their time: too difficult or impossible to implement well on a PDP-11.

(I deleted the part about FORTRAN 77; seems I was confusing it with F90, which is the version that first allowed identifiers longer than 6 characters, dynamic memory allocation and user-defined types).

<comment><USER31> But they fill a different niche. C is about being close to the hardware and using minimal abstractions.

<comment><USER4> There isn't a single C feature that I wouldn't be able to use in say Modula-2.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> > _The simple fact is that most of our past vulnerabilities happened because > of logical mistakes in the code. Logical mistakes that aren't really > language bound and they would not be fixed simply by changing language._

This statement is laughable nonsense. Shall we go into their bug history and point out counterexamples left and right? [Edit:user simias has done this; thanks!]

Every single bug you ever make interacts with the language somehow.

Even if you think some bug is nothing but pure, that logic is part of a program, embedded in the program's design, whose organization is driven by language.

</comment><comment><USER34> > _There. The simple fact is that most of our past vulnerabilities happened > because of logical mistakes in the code. Logical mistakes that aren't really > language bound and they would not be fixed simply by changing language._

That's wrong. A lot of the C mistakes are indeed "logical mistakes in the code", but most of them would be indeed fixed by changing to a language that prevents those mistakes in the first place.

</comment><comment><USER35> In my view, the problem with C in general is that it's a loaded gun with no safety or trigger guard. It's trivial to shoot yourself (or someone else) in the foot, and it requires knowledge, meticulous care and lots of forethought to avoid getting shot.

I very much agree that rewriting existing, stable software written in C is likely not worth the trouble in many cases, but I can't accept claims that the limitations of C aren't the direct cause of tens of thousands of security vulnerabilities, either.

In Rust, even a less experienced developer can fearlessly perform changes in complicated code because the language helps make sure your code is correct in ways that C does not. And you can always turn off the safeties when you need to.

Experienced developers should feel all the more empowered by simply not having to always worry about things like accidental concurrent access, use-after- free, object ownership, null pointers or the myriad other trivial ways to cause your program to fail that are impossible in safe Rust. You get to worry about the non-trivial failure modes instead, which is much more productive.

</comment><comment><USER36> "C is not a new dependency"

To just use a library, rust isn't much of a dependency, either. It's designed so you don't even need to know that it's not C.

Rust would obviously be a build dependency, but that's lessened somewhat because it tries to make cross-compilation easy.

(But this point does apply to pretty much any other language. Curl would not be used as widely if it depended on the Go runtime, for instance.)

</comment><comment><USER37> While I'm definitely not suggesting we _replace_ Curl with a rewrite in Rust (since the current Curl has had decades of good testing and auditing done on it), I am actually very curious how a rewrite in a safer language like Rust, OCaml, Haskell, or Go would fair in comparison in regards to performance and whatnot.

If I were ambitious enough, I'd do it myself in Haskell, but I think it'd be too much work for a simpler curiosity.

<comment><USER38> Most likely I/O will take more time than whatever code is running, so in that aspect it would make no difference. Memory overhead is main concern here. Rust doesn't use GC, so you'll have full control and there should be not much difference in that aspect. Other languages do, which means more sophisticated runtime, less control and more overhead (or writing ugly code to avoid it). Libcurl written in Go/Ocaml/Haskell would require anyone using it to also include runtime of the language, which is usually rather large.

</comment></comment><comment><USER39> This seems like a no-brainer for a re-implementation in rust, but I wouldn't expect that someone would rewrite curl itself in rust, but a new library that does the same things.

<comment><USER40> > a new library that does the same things

Most languages already have HTTP client libraries. (In particular, Rust has Hyper. Ruby/Python/Node/Go have HTTP clients built-in in the stdlib, Haskell has http-client, etc.) Who uses libcurl really? (Spoiler alert… PHP.)

Of course libcurl does FTP and Gopher and all the things, but these aren't commonly required, most applications just need HTTPS.

<comment><USER41> People that write C and often C++ use libcurl. A better library for C/C++ developers would be nice and I believe it could be written in Rust, although that would be a bit of a pain because then you need to integrate Rust into your build system.

<comment><USER42> Do you? For building C projects I certainly don't have to build libcurl, it comes packaged and ready to use with my distribution. The same could be the case with a hypothetical HTTP library written in Rust.

</comment></comment></comment></comment><comment><USER43> I think Rust community increasingly behave like this[1]. They are big on suggesting others the better 'ideas' instead of implementing themselves. So they keep using 'curl' and 'openssl' but tell others to rewrite their software with Rust.

1\. [http://dilbert.com/strip/1994-12-17](http://dilbert.com/strip/1994-12-17)

<comment><USER44> I would say _a portion of_ Rust community---that said, it is that portion that is the most visible, and I think the community well understands what it does mean.

<comment><USER45> I'm not sure the community well understands it at all. The usual rejoinder is something along the lines of "well, I don't see that in the Rust community I'm in."

<comment><USER44> Both /r/rust [1] and the official forum [2] are reasonably regulated and I often see less informed members got warned about their use of aggressive or insulting languages, often directed to non-Rust languages. There are surely other venues with less enforcement (they still commonly observe the Rust Code of Conduct however), but at least I think the main venues and corresponding community heavily tries not to be offensive.

[1] [https://www.reddit.com/r/rust/](https://www.reddit.com/r/rust/)

[2] [https://users.rust-lang.org/](https://users.rust-lang.org/)

</comment></comment></comment></comment><comment><USER46> I don't see why this is an issue, whoever is arguing for a change can write rurl and be done, and see if anyone takes it up in their distributions.

</comment><comment><USER47> I don't think C is a bad language, although I think it could use lists and dictionaries in standard library. std::vector and std::map are the only things that make me pick C++ in an instant, given the choice.

</comment><comment><USER48> While C by itself is not safe, I would argue that no sane development environment uses C by itself. Over the decades of its production use dozens of tools have been developed that make it far safer: *grind suite, coverage tools, sanitizers, static analyzers, code formatters and so on. Those tools are external, otherwise they would make C slower. Something for something.

</comment><comment><USER49> I think it's a bit weird that C and curl are used. If we look at C and OpenBSD or so things might look a bit different.

Also one has a hard time comparing curl with another language, simply because something with curl's properties (take portability for example) doesn't exist.

And no that isn't in defense of anything, just me thinking thinking that measurable points brought up in the discussions don't make sense or exist.

The topic is also a bit broader, as you can easily add in static code analysis, compiler flags, stuff like W^C, stuff like seccomp, capsicum, cloudabi, pledge which might not work (well) in other cases.

It's a great philosophical discussion topics and I don't wanna stop anyone, just hoping people keep that in mind, when they participate, so we don't end up with new dogmas that get thrown around for the next few year, without knowing contexts or meaning of phrases.

Other than that: I really enjoy this discussion. :)

</comment><comment><USER50> I'm curious, of the bugs that _could_ have been avoided by using a "safe" language, how many could have been avoided by using a bounds checking extension like as [https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html](https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html) or [https://github.com/Microsoft/checkedc](https://github.com/Microsoft/checkedc)

Are such extensions popular, and if not, why not? I assume there's always some performance hit, but that might not be a big deal in an HTTP client, for example.

<comment><USER4> Because they aren't portable.

</comment></comment><comment><USER51> CPython also has many vulnerabilities in python rather than C.

It's hilarious reading rust marketers talk about how people should use rust, and yet their software doesn't work as well. It has plenty of bugs.

Then they go on and on about issues which post modern C doesn't have. Guess what? C has a lot of tooling, and yes, it's been improving over the years too. CQual++ exists. AFL exists. QuickCheck exists.

Can your rust project from two years ago even compile? Does it have any users at all?

There's a formally proven C compiler. How's that LLVM swamp going you've built your castle on?

Rust brought a modern knife to a post modern gun fight -- and lost.

<comment><USER52> > Can your rust project from two years ago even compile?

Post 1.0's release date, which is just short of two years, the vast, vast majority should, yes. We've had one or two soundness fixes in those times that would take a trivial amount of updating to do, but that only hit a very small part of the ecosystem.

</comment></comment><comment><USER53> Quite recently I happily used libcurl for C++ project rather than any of those C++ wrappers found at github. Granted there is some non-elegance when you adapt C-style error codes to C++ exceptions and non-C++-idiomatic code style right next to any C lib. Yet libcurl is battle tested (AKA proved to be rather bug free) and has nice clean API unlike.

IMHO it might eventually make sense to use other language/tech/whatever but the bar is quite high and it will quite probably take some serious sustained effort.

</comment><comment><USER54> > The plain fact, that also isn't really about languages but is about plain > old software engineering: translating or rewriting curl into a new language > will introduce a lot of bugs. Bugs that we don't have today.

Don't rewrites, even in the same language usually lead to a better version of the software? I can't really imagine a seasoned C developer introducing completely new bugs in a code base they are already very familiar with

<comment><USER38> > I can't really imagine a seasoned C developer introducing completely new > bugs in a code base they are already very familiar with

Get a CVE list for some Linux distribution, this will open your mind. Happens all the time.

</comment></comment><comment><USER55> What is everyone using curl for that it needs to be written in C (or Rust?).

If it think about my usage, it's like get or post something and see what the returned json looks like. If I need to download something wget usually works without having to remember -O.

But higher level things like httpie are easier to deal with, sane defaults and all that. Maybe they use libcurl...

Are there any re-write userland in ${safe-high-level-lang} projects?

</comment><comment><USER56> Maybe curl could be rewritten in C++ step by step like mpd ([https://musicpd.org](https://musicpd.org)). C++ has RAII for resource management which can help a lot by itself. In my opinion the most hateful thing in C is freeing resources on all exit paths.

Although, curl in C++ - the naming would became inappropriate...

</comment><comment><USER57> I feel blaming a language for errors is like blaming a gun for killing people.

The fact is, mistakes will happen, but in general if you follow the best practices you'll be fine. Failing to follow the best practices means you could be a better programmer. Just because the language gives you an option to do something, doesn't mean you should.

<comment><USER58> "I don't need a safety toggle on my gun I just totes keep it pointed at the ground and unloa-- oh god where's my foot"

<comment><USER59> Still not the gun's fault.

<comment><USER60> In some sense, sure.

But in practice, people always make mistakes. Some guns/programming languages limit the damage of those mistakes more than others. All other things being equal, those guns/programming languages are better.

<comment><USER59> Yup, no argument from me there. There's always room for improvement...

</comment></comment></comment></comment></comment><comment><USER61> Rust might be a great language, but it has not completed the test of time yet. C is 45 years old. Rust appeared 7 years ago.

</comment><comment><USER62> C has still huge market share. Seems that it occurs in 5% of all tech job offers:

[https://jobsquery.it/stats/data.technologies/C](https://jobsquery.it/stats/data.technologies/C)

Stats also showing that average salary for C developers is above average for all tech job openings.

</comment><comment><USER63> Maybe they should attempt writing it using the Isabelle/HOL transpilers to C from SEL4 project. I don't care if it is C or machine code as long as the proof of correctness is complete, down to at least C library.

Curl is small enough to make it relatively easy and used widely enough to make it worthwhile.

</comment><comment><USER64> This has probably been said, in this thread even, but if curl is insecure (for some value of "insecure") then its ubiquity and ease of embedding are a problem rather than a feature. Fuzzy thinking.

</comment><comment><USER65> It's well within reason and capabilities for rust community to write libcurl and curl CLI libraries.

The community should do it, spend a couple of years stabilizing, and then spread the words to others.

</comment><comment><USER66> Software is almost a perfectly open market. If proponents of rust really think their preferred language is better in every way, they are free to rewrite the world in rust, and see the adoption numbers they get. After all, if rust is better in every way, we'd expect the adoption numbers to go up for their rust OS, with a rust http stack and rust web browser. Right?

Telling others to use their language instead of putting their money where their mouth is is truly what irks me about the rust community the most.

Want a rust world? Go write it and ship it.

Oh, and you don't get to complain about C until your PC runs more rust than C

Cool?

<comment><USER67> I'm not sure why I can't complain about problems I have today -- if nobody complained about C ever, I doubt Rust, Go or for that matter, basically any other language project, would have ever gotten started.

It's okay to identify flaws in tools, that's how we make them better. It doesn't make sense to say '[car on fire] you can't complain about that Honda Civic until you develop your own better car, sir, and more people are driving it than not, now please leave the service center -- until then consider the fire normal'.

</comment></comment><comment><USER68> A refreshing read in what seems to be a ongoing deluge of rewrites, languages and frameworks.

</comment><comment><USER69> Another reason: C is beautiful.

<comment><USER10> It is. It is an elegant language, at least I've always found it to be.

</comment></comment><comment><USER59> It is utterly amazing to me to see so many people's attitudes on this issue.

If I cut myself by hasty use of a knife, is it the fault of the knife maker? How is that even remotely rational? If you aren't willing (or don't know how) to use the tool correctly, don't use it.

</comment><comment><USER70> Why does something old (C) have to be bad these days?

<comment><USER71> It's not bad because it's old, it's bad because of how unsafe it is. There are older languages than C that are safer, but they didn't gain the popularity C did.

</comment></comment><comment><USER72> >C is not the primary reason for our past vulnerabilities

Completely false. C is a disaster.

</comment><comment><USER10> This is a great little read and encapsulates the other side of the 'rethink the way' trend-ism of some HN new lang advocacy. C is fine, C is good. It is widely understood, it is a systems staple, and it is not dangerous in knowledgeable hands. Rocking the boat is fashionable.

<comment><USER73> > it is not dangerous in knowledgeable hands

For crying out loud, this is patently false.

C isn't as dangerous if you really know what you're doing and you never make mistakes. I would bet fewer people know what they're doing than _think_ they know what they're doing, and the set of people who never make mistakes is entirely empty.

<comment><USER10> Well you know..that's just like your opinion man. Opting out of this site at this point. A bunch of 6-12 year idiots (recognizably) telling people what they think they know that they don't know. It's silly recursive.

<comment><USER73> You're right, my reply was unnecessarily harsh. I apologize.

</comment></comment></comment></comment><comment><USER74> Why are you saying this? Who asked? I always imagined it was written in C.

<comment><USER75> Dude, it's in the first sentence.

> Every once in a while someone suggests to me that curl and libcurl would do > better if rewritten in a "safe language".

And so he minimally addresses that and some other reasons for sticking with (and originally choosing) C89.

<comment><USER74> Oops. I read everything after the first subheader.</comment></comment></comment>


Ask HN: Using Google Voice Number for your startup? - <AUTHOR>

I'm getting ready to setup a number for my startup and wondering if people are finding Google Voice reliable and of high enough quality to use as their main number.
We'd like to start contacting some rather large companies to sell our product and we want a convenient way to relay around our business number to cell phones or other connections as needed.
Any advice on setting up a business number for a small startup is appreciated.. <comment><USER2> I've tried lots of different phone systems and still haven't found a good solution yet, but hopefully my experience is instructive:

RING CENTRAL: RingCentral provided a toll-free number for me. Their interface is awful and they're just generally not that innovative, but they accomplished the task for $15 / mo or so. I wouldn't use them again, but only because there was no "wow."

GOOGLE VOICE: Google Voice is hit or miss. The connection is spotty, the dial out sometimes just doesn't work, there's a slight delay in the connection when answering etc. It is promising as a personal product, but nowhere near business quality. I've tried on two occasions...and both times got frustrated and needed to switch. Contrary to what others have said, you can have a phone assigned to two Google Voice accounts, but one must be marked "home/office" and it won't be able to send or receive SMS messages. It's confusing because I'm sure they're trying to avoid this use case.

GRASSHOPPER: I have been using Grasshopper for 3 months after hearing recommendations from Jason Fried and Mixergy. I find their interface to be really unintuitive and difficult to use.

They have great support, but I had to rely on it too often. I called 5-6 times to set up basic Google Voice functionality (route calls to my cell phone, have voice mail). The Java program for recording your voicemail greeting was wonky and broke often. The recording was poor as well. They encourage you to hire voice actors to do the work, but I want my voicemail to sound like a human, not a radio robot. They should simply allow you to upload an MP3.

There's no good way to dial out. With Google Voice you can log-in to the web app or use their mobile app. With Grasshopper, the only way to dial out is to call a number first, then dial the number you want to call. With this approach, sometimes connections were refused that were later successful from my cell phone. Nice people and I love what they're doing with Chargify, but I plan to move to something else...

TWILIO: I considered Twilio and will most likely use it for other aspects of the business (click to call, sms follow-up). But I ultimately decided it was better to use a solution designed for this purpose rather than spend developer resources making Twilio work for us. It will be cool to see applications built upon Twilio that solve problems like this.

LINE2: Line2 looked interesting, but recently had crippling DDOS problems and is iPhone only. It also seems best suited for a single person consultancy rather than a company.

ONSIP: I recently decided to make the move to OnSip. They were also recommended by Jason Fried. Since they are essentially just providing virtual PBX via SIP, you can choose from a wide selection of phones, apps from third party developers etc. So I plan to purchase an office phone (with a cord!) and use that during work hours. When I'm not in the office, or for off-hours, calls will be routed to my cell phone and I'll use an iPhone app to dial out.

<comment><USER3> Thanks for trying Grasshopper.com on my recommendation. I'm curious about what UX issues you had.

If you want to tell me, please email me mail at awarner dot com

I worked hard to get them as a sponsor because I thought they were very easy to use.

</comment></comment><comment><USER4> One issue with Google Voice is that if you already have a personal GV number pointing to a phone number, you can't create another GV number (ex. for business) that points to that same number.

A GV-like service that was built for businesses is Phonebooth (<http://www.phonebooth.com/>). Give it a try, it's freemium!

<comment><USER5> Thanks for the tip about Phonebooth, just signed up. My favorite feature about GV is that I can see that the call is being fwd (I know its not a personal call to my cell) and then I can answer accordingly.

This feature is a must-have for me, as I would prefer not to answer every call with my business tag line :)

</comment></comment><comment><USER6> GV is a fantastic program. I have hit problems because of the limitations on the number of times you're allowed to connect your cell phone number to GV. That being said, I think it's against their terms to use it for commercial use.

Check Grasshopper.com. I am not a customer of theirs.

</comment><comment><USER7> I've been using GV for almost a year now and for the most part it's been great. I have had issues with certain people trying to call me as well and getting busy signals or operator error messages. From what I've read I think this has to do with routing tables not being updated in certain states for certain GV number blocks, and that it's really hard to get resolved.

</comment><comment><USER8> I'm using one as a business line, but would not recommend it. There's a brief period of silence before connecting, which results in constant 'do you hear me' questions, and generally poor voice quality overall.

I like the attempts at transcription for voice mail, but find the voice mail difficult to configure otherwise. Sometimes I get messages on the ring-to phone, sometimes on GV. There's no way to set the number of rings before pick up.

I'm having a much better experience with standard VOIP numbers through Callcentric, to the point that I'm looking at trying to port out the Google Voice number. Has anyone had any success in porting a number out?

<comment><USER9> I successfully ported a number to Callcentric before GrandCentral became GV. After GC -> GV, the number magically returned to GV, which is fine by me with the improved feature set.

</comment></comment><comment><USER10> I've used Google Voice for one of my companies since 2007, and it's been great.

However, I replaced it with Grasshopper (<http://www.grasshopper.com>) a few months ago and haven't looked back. It is much better for inbound calls and is well worth the $10/mo for the entry-level plan. You can setup an 800 number (or a vanity 800-number for $30), and record an entire phone tree for various "departments" like support, sales, etc.

Starting out as a 1-man team, all of these extensions routed to my own cell phone of course. But then as I grew, it was easy to login and change the destination of each extension to various team members. Both of my companies are primarily B2B, so being able to give the user experience of having a stable central hub, when we in fact work mostly remotely, is comforting to existing and potential clients. Without this, we'd have to try forwarding calls to each other's cell phone numbers, or telling the client to try dialing the other person's number directly, both of which are simply unacceptable.

The one downside of Grasshopper is that, as of now, you are still unable to make outgoing calls through the number, since it doesn't have a GV app for Android or iPhone.

</comment><comment><USER11> I work for Ringio (<http://www.ringio.com>) so my advice is potentially subjective. Biggest differentiators:

* You get a screen pop on your computer (or your Android) when a call comes in, with the whole interaction history between the caller and anybody in your business, so your chances of sounding like you know what you're talking about are higher.

* It syncs in real-time, 2 way, with your Google Contacts and makes it a snap to share contacts between colleagues.

* It gives you fine-grained control over your Caller ID when making phone calls, so people who call you back are reaching you where they should (e.g. a support call shows your main company number, but a personal call shows your personal business number)

* Unlike most of the other services, Making an outgoing call is not an afterthought, it's well built into the system as a full feature. And most startups trying to get customers do a lot of outbound calls, and rarely get called. (10:1 ratio)

</comment><comment><USER12> I have had a good experience using Twilio to handle and route incoming sales and support calls.

</comment><comment><USER13> It's fine as a forwarding number, but it's a little odd dialing out.

Twilo and Tropo (which runs on voxel) are both alternatives you may want to look at.

</comment><comment><USER14> #1 questions: How prevelant is Android at your startup?

Most Android: Do it. Not Android: Use Grasshopper/Phonebooth

</comment><comment><USER15> Google Voice was great for me until I started my business and needed a toll free number as well as an extension for each of my 2 employees. I looked at RingCentral and Grasshopper and ended up going with a similar company called my1voice.

</comment><comment><USER16> I believe this is a violation of the TOS for Google Voice. I've heard great things about phonebooth.com, which is especially for commercial use and starts as a free service.

</comment><comment><USER17> You might want to look into a cheap plan from a paid provider like Vocalocity. We're using them at the moment and it's pretty solid.

</comment><comment><USER18> Skype?

Apparently they now route a decent % of all calls.

</comment><comment><USER19> I use it and love it for personal use. I would not trust it for business use yet. Text syncing goes out once every two weeks, sometimes for an entire weekend. It requires manual refreshing in the GV app. Froyo's new push notifications should reduce this problem.

I've been told that people have tried to call me and got busy signals multiple times.

<comment><USER20> I agree with you</comment></comment>


The Complete, Unofficial TEMPEST Information Page - <AUTHOR> http://www.jammed.com/~jwa/tempest.html <comment><AUTHOR> A lot of the links are dead now, but there's a wealth of information in here if you poke around with the Wayback machine.</comment>


Peter Thiel Said to Join Trump's Presidential Transition Team - <AUTHOR> https://www.bloomberg.com/news/articles/2016-11-11/peter-thiel-joins-trump-s-presidential-transition-team <comment><USER2> Extensive discussion: [https://news.ycombinator.com/item?id=12926678](https://news.ycombinator.com/item?id=12926678)

</comment><comment><USER3> Looks like 1.25M well spent now.</comment>


All work and no play makes Jack a dull startup - <AUTHOR> http://www.betabeat.com/2011/11/30/return-of-the-diaspora-after-a-taste-of-the-valley-new-york-techies-are-coming-home/

<comment><USER2> I dunno.. it's not like NYC is any better. Sure there's lots to do, and lots of people, but it can get more lonely when 99.999% of your daily interactions are with ppl you don't know. Lots of dehumanization.</comment>


LibreOffice has improved its looks and added more interoperable features - <AUTHOR> http://www.zdnet.com/article/the-best-desktop-office-suite-libreoffice-gets-better/ <comment><USER2> I am fine with the "tried and true menu-based interface that any Microsoft Office 2003 user will recognize at a glance" but not sure if that requires the program to look like a program from 2003 too, especially when touting improved looks.

</comment><comment><USER3> I just downloaded the Debian packages and installed them on Ubuntu 14.04 following the instructions.

The installation went fine and I immediately tried if it would render better some MS Word documents than the Libre Office 4.x something that was installed by Ubuntu. And indeed the documents look better, though not 100% as in Word.

But the colors on some menu items are wrong, i.e. with inversed colors.

I am wondering, if there is a chance that this version of LibreOffice will be integrated into Ubuntu LTS 14.04 and if how long it would take.

</comment><comment><USER4> > Mac OS X x86_64 (10.8 or newer required)

10.8 and forward have serious problems. What specifically about stable versions of OS X makes LibreOffice incapable?

<comment><USER5> _10.8 and forward have serious problems._

But old versions are totally unsupported in terms of security fixes. So if your computer is being used to access the Internet in general, you really need to be on 10.9 or newer. And it won't be long before Apple stops pushing security fixes to 10.9.

There's no LTS equivalent of OS X. There probably should be, but it's a consumer OS so Apple has no real incentive to do that.</comment></comment>


Less is More: How SeeClickFix Improved Engagement By Reducing Visual Clutter - <AUTHOR> http://blog.optimizely.com/redesigning-your-homepage-ab-test

<comment><USER2> I'm a Optimizely user and I find the engagement score to be the most suspect metric to use to validate anything. Especially for something as important as your homepage. Was there not a real goal state they could have tested other than "did someone click anything?"?

<comment><AUTHOR> Dan from Optimizely here. I agree that engagement isn't always the best metric to use to determine the effectiveness of a variation and in this case it probably would have been better for them to track the submissions of the main form on their homepage. That said for large whole page changes it is a great way to determine whether or not people are more likely to engage on the page in some way vs. bouncing.

The original inspiration for Optimizely came out of my experience as the Director of Analytics for the Obama 2008 campaign where we used Google Website Optimizer and Omniture Test & Target. One of the things that was frustrating with GWO was only being able to measure one conversion goal. With Optimizely you can measure as many goals as you like and see the holistic impact of the changes you make. In this case I think they should have also measured the conversion rate of the main form and see the impact this variation had on it. We will do a better job of evangelizing lessons learned and best practices for our customers going forward!

Appreciate the feedback and keep it coming!

</comment></comment><comment><USER3> Have they seen clicked and fixed the broken android app yet?</comment>


Court: RapidShare doesn't need to filter user uploads - <AUTHOR> http://arstechnica.com/tech-policy/news/2010/05/court-rapidshare-doesnt-need-to-filter-uploads.ars

<comment><USER2> That's pretty huge, given that in other European countries _linking_ to copyrighted content has been found to violate the law, rapidshare actually distributes the files themselves.

This is likely not the last shot though, the 'ueberlandesgericht' is not the highest court.

Edit: I've been reading the German response by 'telemedicus' linked in the article, here are the highlights (German native speakers please correct me if I'm wrong, stuff in brackets I've added):

\--

1) rapidshare is neither the party that commits the crime nor a participant

2) rapidshare does not make the data publicly available (you need a downloadlink)

3a) checking the filenames is not applicable because you can choose a filename, on the other hand the risk exists that legitimate data would be refused

3b) a datatype can not be blocked because there is no indication a datatype is tied to the legality of the data

3c) a tie with IP addresses is to be declined because IP addresses are regularly used by multiple people

3d) a manual checking of the lists of links can not be required because there is no business relationship between hoster and the people that host lists of links

\--

from [http://www.telemedicus.info/urteile/Internetrecht/Haftung- vo...](http://www.telemedicus.info/urteile/Internetrecht/Haftung-von- Webhostern/1017-OLG-Duesseldorf-Az-I-20-U-16609-Keine-Haftung-von-Rapidshare- fuer-Urheberrechtsverletzungen-Dritter.html)

I'm especially amazed at '1', that they're not even seen as an accessory is very interesting as a conclusion.

<comment><USER3> That's a accurate translation :)

I would add that 2) also refers to the business model of Rapidshare: uploaded files are by default confidential. Only users make downloadlinks public, not Rapidshare. (Is that true, by the way? Is the only way to search Rapidshare to search for published links somewhere on the internet?) Giving the user the option of publishing the downloadlink cannot be prohibited. (I would guess because such a feature can have legitimate uses.)

<comment><USER2> > Is that true, by the way? Is the only way to search Rapidshare to search for > published links somewhere on the internet?

I think it is, google lists some 15,000 files in the 'files' subdirectory of rapidshare ( <http://www.google.com/search?q=site%3Arapidshare.de> ), I can't imagine that's all of them.

</comment></comment></comment><comment><USER4> The greatest part is that the court thinks distributing illegal content isn't the main part of thier operation therefor they are allowed to continue the service in general. I seriously doubt that more than even 1% of the traffic is legit.

<comment><USER2> Why do you doubt that?

I run a small filedump ( <http://files.ww.com/> ) as a service for the general public and from what I can see by looking at the filenames alone (and contrary to the German court I do think they say something about the content) I'd say well over 90% is legit.

I do have a search facility on there, that's something rapidshare does not have, I think I only got away with that because it's small enough to be under the radar.

For sure there are copyrighted files in there, and I do not allow the 'rar' format (because it was universally used to upload full length movies) but the majority are small files, single images, word documents or cad files, and most people are nice enough to remove the files when they're done with them.

It was built as a convenience to get around email attachment limitations.

edit: >The greatest part is that the court thinks distributing illegal content isn't the main part of thier operation therefor they are allowed to continue the service in general.

Where did you read that?

</comment></comment><comment><USER5> >It's a huge win for the site, which suffered a major setback in the case before a Düsseldorf court back in 2008.

A huge win for Rapidshare, a loss for website owners, since this implies that the responsibility lies on those who host or publish links to Rapidshare.

<comment><USER2> I'm not so sure here, if hosting is legal then it seriously undermines the 'linking' theory, after all hosting used to 'trump' linking in the past in terms of 'how bad' it was according to a variety of court decisions.

The whole reason the linking was made illegal in the first place was because the 'hosts' were usually in places where prosecution was tough, rapidshare is a 'sitting duck' and they've just won this case.

edit: it might even be that this makes music lockers in Germany legal!

<comment><USER5> I think Rapidshare not being responsible for infringement must be contingent on what Rapidshare does to fight it.

Well they have damn good lawyers, since now they don't have to check filenames, check checksums, IP addresses, manually check lists of links (according to your post below) and whatever else.

So what does that leave Rapidshare with? Do they just have to manually check files when a copyright owner submits a complaint with a list of links?

(On a sidenote, I could make a pretty good link finder and make it send complaints automatically, there must be some good money in offering such a service to copyright owners)

<comment><USER2> > On a sidenote, I could make a pretty good link finder and make it send > complaints automatically, there must be some good money in offering such a > service to copyright owners

Anybody here probably could, and I'm sure the plaintiffs are aware of that possibility.

Already DMCA takedown requests are generated in an automatic way, but that doesn't change much because another upload is minutes away.

It's a real problem for the copyright fat cats, which is why I don't doubt they'll appeal this to the German national high court.

If they call it quits now I predict a serious increase in German hosting capacity in the near future.</comment></comment></comment></comment>


DNSimple DDOS Attack - <AUTHOR> http://dnsimplestatus.com/incidents/v0x4h75gxf7x <comment><USER2> We're kinda tied into DNSimple since we use an ALIAS record for our bare/naked/root domain. Amazon's Route53 supports aliases, but via a 301 redirect, which doesn't work in an SSL context (without browser warnings).

Nonetheless, we just spun up a Route53 zone, exported our zone from DNSimple, imported to Route53, and hand-migrated our ALIAS records to static A records in the new zone.

Not perfect or permanent, but we've gotten around the outage. Also, I just learned that pointhq has (seemingly-undocumented) support for ALIAS records in the same style as DNSimple, so this could be another avenue to explore.

<comment><USER3> How are you exporting the zone with things as they are?

<comment><USER2> Oof, really good point – I suppose I got lucky in that I was at dnsimple.com just a few hours ago for other purposes. Their DNS was still cached for me, and it all worked flawlessly. I didn't even suspect their outage extended to their web servers, though that makes perfect sense.

FWIW, the IP I have cached is 220.127.116.11.

<comment><USER4> How were you able to find out what IP was cached for a particular domain?

</comment></comment></comment></comment><comment><USER5> We can watch this happen live @ [http://map.ipviking.com/](http://map.ipviking.com/)

Fascinating traffic floods from various locations, but the attack is not continuous.

<comment><USER6> How does this link show this specific attack?

As far as I understand, ipviking simply hosts honeypots around the world and uses those to graph "attacks" against IP blocks, etc.

I would _very much_ like someone to correct me if this assumption is incorrect, because it'd be neat to actually watch targeted DDoS attacks, but I don't think that's what ipviking is offering.

</comment></comment><comment><USER7> Free solution that worked for me: Set up a free account on cloudflare.com, duplicate all dns records (thankfully I have a simple setup)... but next time I will keep a backup zone file!

FYI - Instead of an Alias record on DNSimple, CloudFlare will allow a CNAME record for the root domain using "CNAME flattening".

You can now set CloudFlare's DNS service to "bypass Cloudfare" on all records by clicking the icon so you don't get any of their magic (unless you want it).

Then add CloudFlare's 2 nameserves to your domain as your first 2 name servers. No need to remove dnsimple's name servers.

Now you have 2 DNS providers in case one fails, just make sure the records are the same across them both!

<comment><USER8> Hey thanks for the post, but how do I add CloudFlare's nameservers? DNSimple won't let me add NS records on the root domain: "You may only delegate subdomains". So in theory, I can fix the www subdomain, but my naked redirect to www won't happen if DNSimple is still down.

Any ideas?

<comment><USER7> You would set your name servers with your registrar, such as godaddy. If dnsimple is your registrar as well as your DNS provider you may be out of luck until they come back online. The help page is here though: [http://support.dnsimple.com/articles/setting-name- servers/](http://support.dnsimple.com/articles/setting-name-servers/)

</comment></comment></comment><comment><USER9> DNS is so straightforward, so easily distributed, and so fundamental, that I'm always astounded when it's a single point of failure for so many operations.

I wonder how many of the affected companies _do_ have redundant appservers and load balancers, but missed this piece of the puzzle...

<comment> mike-cardwell I'm surprised more places don't run their own DNS. It's not that difficult to do and it means you don't have to rely on another third party for service.

<comment><USER10> Well if this is an attack to get at one of DNSSimple's customers, running your own DNS would be a much easier target. Which is to say that if _you_ were the target, you would already be hard dead by now rather than struggling as DNSSimple deploys defenses.

I agree though that it is a pretty simple service to run for a small domain.

<comment> mike-cardwell If you're being targetted directly, then _all_ of your services need to be DDOS proof, not just DNS. The more third parties you add, the more likely you are to be taken out by accident. If you have your own web server, you should dump Bind or PowerDNS on it and write a zone file. Problem solved.

</comment></comment></comment></comment><comment><USER11> Can someone help me understand what happens to email sent to a domain hosted by DNSimple while it's down?

I'm hoping it will get queued by the sending server, and make it's way back when DNSimple is up and running. Is that correct?

<comment><USER12> It will depend on the configuration of the sending server. Some will retry for a while, some will return failures.

<comment><USER11> Thanks!

</comment></comment></comment><comment><USER13> I moved from Zerigo to DNSimple, and it's been awesome until now!

What can you do to prevent this in future? Can you run multiple DNS providers simultaneously? So, ns1/ns2 go to DNSimple, and ns3/ns4 go to another provider?

<comment><USER14> Yes - that should work. I'm about to make that change to bring back our site. 2 on one name server, 2 on another.

<comment><USER13> Cool. Do you need a provider that supports 'zone transfers'? Or is that only to keep things in sync _automatically_?

<comment><USER15> > Do you need a provider that supports 'zone transfers'?

No.

> Or is that only to keep things in sync automatically?

Yes.

<comment><USER13> Do you know of any providers that will work nicely/automatically with DNSimple?

<comment><USER15> I don't unfortunately.

</comment></comment></comment></comment></comment></comment><comment><USER16> If you have an active DNSimple web UI session (or API key) you can change your root nameservers by hitting their web tier directly at 220.127.116.11.

We've successfully switched our domains over to nsone.net.

<comment><USER17> Even without an active session, I was able to get this working by adding an entry to my /etc/hosts file with that IP and dnsimple.com.

<comment><USER18> Thanks for the tip! Switched to NSONE.

</comment></comment></comment><comment><USER19> For anyone else who needs to mitigate this in a hurry:

Set up a new account on another host that does ALIAS records (I used pointDNS)

Create your new record without much in it

Change your nameservers on your domain now - they'll take time to propagate

Fill in the records on your domain. If you can't remember them, print out most of your existing records with

dig yourdomain.com ANY

Add the rest of the records to pointDNS

Wait for the new Nameservers to propagate (0-24 hours - it took 15-30 min for us on a small-medium traffic domain today during sales crunch)

<comment><USER9> For those with a more deterministic bent: "propagation" time has a maximum bound of your TTL, which will show with any dig queries.

<comment><USER20> Propagation is bound at the DNS TTL _plus_ whatever time it takes your DNS provider/setup to relay records to all of its authoritative servers.

<comment><USER9> Hmm, never considered that. Is it a slow, static process for ISPs to do that? I just assumed that they ran more-or-less stock DNS resolvers with in-memory caches.

</comment></comment></comment></comment><comment><USER21> Here's where you can request your cached SERVFAILs be flushed from Google's public DNS (i.e. 18.104.22.168): [https://developers.google.com/speed/public- dns/cache](https://developers.google.com/speed/public-dns/cache)

<comment><USER22> Thank you, I wish I could buy you a beer for that

</comment></comment><comment><AUTHOR> "30 minute ETA from our network provider to begin scrubbing traffic in a location with capacity."

[https://twitter.com/dnsimplestatus/status/539551209452232705](https://twitter.com/dnsimplestatus/status/539551209452232705)

<comment><USER23> It's surprising that they're appear to not be multihomed...

[http://bgp.he.net/AS32771](http://bgp.he.net/AS32771)

Unlike Dyn or CloudFlare:

[http://bgp.he.net/AS33517](http://bgp.he.net/AS33517) [http://bgp.he.net/AS13335](http://bgp.he.net/AS13335)

<comment><USER24> They're in ServerCentral's datacenter and ServerCentral is very much multi homed. They wouldn't gain anything by doing native BGP to all these peers in the exact same datacenter when SC's backbone will handle this stuff for them.

<comment><USER15> Doing native BGP would allow them to anycast, which would increase their reliability and allow them to sink traffic much more easily. DDOS traffic sink starts announcing your AS and anycast IP block close to the traffic source, sinking that traffic and allowing real traffic through.

<comment><USER24> I'm pretty sure they're only in one of Server Central's datacenters. Anycast won't help. That's why I said they don't gain anything by directly peering.

</comment></comment></comment></comment></comment><comment><USER25> Does anyone have a simple explanation or link to an article / blog that explains the naked domain / ALIAS "problem" that DNSSimple solves? I recently set up DNS with DNSimple (due to nudging by Heroku) and am affected by this DDoS. I am still struggling to understand the exact nature of this issue. All of Heroku's documentation is pretty cryptic (to me):

"Some DNS hosts provide a way to get CNAME-like functionality at the zone apex using a custom record type. " .. and then on to suggest DNSimple as their first suggestion.

<comment><USER26> [http://blog.cloudflare.com/introducing-cname-flattening- rfc-...](http://blog.cloudflare.com/introducing-cname-flattening-rfc- compliant-cnames-at-a-domains-root/) is a reasonable explanation. fundamentally a CNAME says "when you get queries for this name, go look at this other name instead". among other things, doing a CNAME at the zone apex means resolvers can't then find your NS, MX, or other records at the apex, which is problematic.

</comment></comment><comment><USER9> For those wondering about alternatives to ALIAS: if you use a www subdomain, then you can simply use CNAMEs. (Though the appearance is a matter of taste...)

Google, Facebook, etc, all use this approach.

<comment><USER27> Yes, but if someone visits your apex domain directly, you want to redirect him/her to the www version... And if you use cloud based hosting where the IP can change quite often, that's a pain to maintain manually.

</comment></comment><comment><USER28> Anyone switching from DNSimple? I really don't want to, but we've been down for almost 3 hours. I've seen chatter about Cloudfare and it looks pretty good, reviews?

<comment><USER29> We switched periscope.io from DNSimple to Amazon Route 53. DNSimple doesn't have an exporter so it took about an hour, including having one engineer review the other engineer's work.

Many customers were able to resolve the domain in the minutes immediately following the switch, and the rest seem to be trickling in.

<comment><USER30> Are you talking about a zone file exporter? DNSimple does have one, we just used it to migrate to Route53. [http://support.dnsimple.com/articles/zone- export/](http://support.dnsimple.com/articles/zone-export/)

EDIT: right, must have been able to log in during a brief period where dnsimple was not down.

<comment><USER29> That page doesn't load for me. :)

We went by this:

[https://twitter.com/dnsimple/status/539521794802483202](https://twitter.com/dnsimple/status/539521794802483202)

[https://twitter.com/dnsimple/status/539520808599957505](https://twitter.com/dnsimple/status/539520808599957505)

</comment></comment></comment></comment><comment><USER31> DNSimple is my registrar and (was my only) DNS provider. Now that they're back up I've exported the zone file and imported it to route 53 for redundancy in case this happens again. I also I updated the name servers in DNSimple to be 2 route 53, and 2 DNSimple, in that order. Is that the right way to do it? Does the order of the NS records matter? I set them up so that they're in the same order in both places.

<comment><USER32> That should be right. I'm doing the same thing with CloudFlare. However, it appears that DNSimple won't keep your secondary name servers in the order entered. They are showing for me sorted alphabetically. Apparently, they are working on providing this ([http://blog.dnsimple.com/2014/12/incident-report- ddos/](http://blog.dnsimple.com/2014/12/incident-report-ddos/)) for failover in case of an event like this again.

</comment></comment><comment><USER33> I wrote a follow-up article about what we at Canopy.co learned from this incident. Check it out (this covers and expands on some of the ideas talked about here):

[https://medium.com/@brianarmstrong/youre-probably-doing- dns-...](https://medium.com/@brianarmstrong/youre-probably-doing-dns-wrong- like-we-were-6625efaed390)

</comment><comment><USER34> Unfortunately, it's not the first time it happens, my app is down and customers unhappy.

I always wonder, why is it that someone wants to attack a small company like DNSimple ? Is it that they were blackmailed and did not surrender to the criminals? If so, why would anyone be interested in blackmailing such a small company?

<comment><USER2> More likely, I'd guess based on past experience, it's that someone wanted to take down one of their customers, and decided (or found) that the weakest link was the DNS provider.

</comment></comment><comment><USER32> You can use my cross-platform cli for dnsimple to export your zone files easily to txt or json format: [https://www.npmjs.org/package/dnsimple- cli](https://www.npmjs.org/package/dnsimple-cli)

dnsimple domain record list example.com > example.txt

OR

dnsimple domain record list example.com --json > example.json

</comment><comment><USER35> DNSimple says it was not a direct attack on them but rather domains being brought over by new customers. Does anyone know the actual target?

</comment><comment><USER36> RubyGems.org and Travis-ci are down as a result of this! Not helping with my productivity this morning.

</comment><comment><USER37> What are the recommended practices to prevent too much down time when your DNS provider goes down?

<comment><USER38> My site is currently offline from this attack. I am considering that providers like DNSimple simply cannot provide the networking availability to mitigate these kinds of attacks. This is because the solution to these kinds of attacks, often, is that you need a larger pipe than the attackers. Very few people are good at both <some service> and having a huge pipe. For web apps, you can use CloudFlare, which does have a bigger pipe and is designed to mitigate this. But DNS is not a web app, so you can't just put DNSimple behind CloudFlare.

Hence, I'm going to try CloudFlare (assuming they take over DNS hosting, I need to check) and Google Cloud DNS, because then all parts of my site (from DNS to CSS hosting) will be with providers with bigger pipes than attackers can create. Hopefully that will prevent this kind of attack from taking my site down.

<comment><USER39> Yes, CloudFlare has a full-featured DNS offering, even if you don't use their proxying services.

<comment><USER40> Which has had a lot of problems this past week:

[https://news.ycombinator.com/item?id=8665367](https://news.ycombinator.com/item?id=8665367)

<comment><USER39> CloudFlare != CloudFront

<comment><USER40> My apologies, cloudfront had issues, cloudflare did not.

</comment></comment></comment></comment></comment></comment><comment><USER41> Can anyone expand on what this means: "This attack is volumetric in nature." (?)

<comment><USER42> According to [http://www.arbornetworks.com/attack- ddos](http://www.arbornetworks.com/attack-ddos):

"DDoS attacks...will generally fall into one of three broad categories:

Volumetric Attacks: Attempt to consume the bandwidth either within the target network/service, or between the target network/service and the rest of the Internet. These attacks are simply about causing congestion."</comment></comment>


10 useless résumé words – and 10 eye-catching ones - <AUTHOR> http://msn.careerbuilder.com/Article/MSN-2648-Cover-Letters-Resumes-10-useless-r%C3%A9sum%C3%A9-words-and-10-eye-catching-ones/?SiteId=cbmsnhp42648&sc_extcmp=JS_2648_home1&gt1=23000

<comment><USER2> It all sounds very recruiter-ish to me - where the keywords count more than the substance, regardless of whether they are the right or the wrong words.</comment>