Unikernels are secure - <AUTHOR> http://unikernel.org/blog/2017/unikernels-are-secure <comment><USER2> > Good luck guessing that address. Our own unikernel, IncludeOS, randomizes > addresses at each build, so even with access to source code you still don't > know the memory layout.

"There is one mortal sin in computer security (or by the way, in any kind of security) that is feeling safe. It's just a variation of pride to be true, but it's very deadly. Blindly trusting a protection technology is an extreme error."

Read up on DEP. Randomizing function addresses at each build is useless when it comes to attack mitigation. You need to randomize addresses at each execution.

<comment><USER3> is linux randomizing is per exec ?

ps: BSD have started to randomize at boot time, fun times

<comment><USER4> > _is linux randomizing is per exec ?_

Not entirely sure what you're meaning to ask, but yes, Linux does KASLR and tries very hard not to leak pointer addresses from the running kernel to unprivileged userspace:

[https://lwn.net/Articles/569635/](https://lwn.net/Articles/569635/)

It's been enabled by default since the upstream 4.12 kernel, and usually well before that in distros.

<comment><USER5> KALSR's not the same as ASLR (although ideologically related). ALSR has been around for a good number of years in userspace via randomize_va_space sysctl

(edit I presume that's what the poster above mentioned re: per exec)

<comment><USER3> yes ALSR, sorry, acronym fail on my part. So ALSR does randomize bindings on each execution ?

<comment><USER6> Yes. If I run e.g. `ldd /bin/bash` multiple times, it shows different memory addresses each time. That's ASLR.

<comment><USER7> cat /proc/self/maps is a better way to see that. If it's built with PIE, the executable base is randomized. Some distributions use full ASLR across the board (Alpine, Android, ChromeOS, Hardened Gentoo) while others don't yet enable PIE globally or have only recently started and it isn't all pushed out yet (OpenSUSE, Fedora, Debian).

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I would hesitate to call something Secure unless some major pen test effort were engaged to try to break it.

This is a corollary to "If it isn't tested it is broken". (Another corollary is "Even if it is tested, it may still be broken.") This is more so with security.

Just looking at some of the assumptions, e.g., that the lack of a shell significantly increases the difficulty of an attack, leaves me with doubts about the claims.

<comment><USER9> Hi author here. I agree wholeheartedly. I wasn't thinking in absolutes, but I absolutely can understand how it could read that way. I could have titled the post "Unikernels are resonably secure", but then nobody would have read it.

I was doubtful about mentioning the lack of shell. Technically it doesn't really do much in terms of security, but it does make a compromise harder. And currently, where we stand, a lot of the security comes from things being really, really hard to compromise. Guessing adresses, not having a shell, potentially no filesystem, etc.

<comment><USER8> With _" Unikernels are reasonably secure", but then nobody would have read it._, you might also take into account whether the audience, having read it, are happy that they did. The title sounded pretty absolute.

So you do have a noble goal. When I am asked to assess software, to gain a first order approximation, I often look at the culture of the organization that produced it. On the high end, that often translates to some sort of formal process involving un-fun letters like 'ISO' and 'SOC'.

For smaller organizations, or OSS software, I try to get a feel for how the developers seem to be thinking about security. Some of the cultural things I see in your writeup are encouraging--Smaller Codebase, Removing hardware emulation, Cutting off access to ring 0--all bode well for how you are thinking about producing secure software.

But there are some things that are missing from your description. What is your development process? In particular how and when do you attack your assumptions about how the code actually works? What flaws have you found in your testing? Zero findings could mean 1) it wasn't tested 2) it wasn't tested very hard 3) the testers were not very good at security testing.

And as OpenBSD's history has illustrated, some things are totally secure until they aren't.

</comment></comment></comment><comment><USER10> I'm interested that they didn't list the "old" reason people thought unikernels _could_ be more secure. That is that they could be small enough to be _completely_ written in higher languages. With something like [https://github.com/GaloisInc/HaLVM](https://github.com/GaloisInc/HaLVM) you could bring to bear formal methods in more straight forward ways.

This of course left the host still needing to be secured using traditional approaches but that surface area was smaller.

I'd buy that you can't list that in an article about why _all_ unikernels are _already_ secure, but that seemed to be the heart of the pitch to me when I first started hearing it.

<comment><USER11> well, you also have to keep in mind that this article is written by the CEO of a company producing a particular unikernel implementation -- one that isn't written in a higher language.

</comment></comment><comment><USER12> So to summarize, unikernels stop a couple of attack vectors (syscalls and running other programs (notably shells) that are loadable from well-known paths). Address randomization is not unique to unikernels, and the other benefits are theoretical for the time being until hypervisors provide more unikernel support (though the mention of paravirtualization makes me think performance (particularly network) in this theroetical hyper-restricted mode will be poor).

While I certainly sympathize with the idea that the typical kitchen-sink deployment of a full suite of administrative/troubleshooting/build tools on an application server is a security risk, it seems the actual improvements enumerated here are relatively small potatoes.

Apologies for not knowing a lot about the state of the art here, but I'm curious about how these unikernels address VM-internal security (eg, network, filesystem, inter-process level stuff). Do you farm all of that out to the hypervisor? Design around the lack of it? _Is_ there even "inter-process stuff"?

</comment><comment><USER13> So, basically, we're going to run all your code at ring0, so a single bug is now either a total DoS (kernel shuts down) or an exploit vector straight to ring0. Although they talk hypothetically about a defense for that involving the MMU, this is not implemented in IncludeOS.

The build should not be relied on to be secure either; certain classes of memory disclosure bugs could leak out enough memory to let you work out e.g. a ROP payload, which wouldn't require injecting any machine code necessarily. Plus, a long-lived machine, or a single instance deployed across many machines, would present insufficient diversity to protect against a determined attacker. The gist here appears to be the notion that their build diversity gives them most of their security, while they've eliminated most of the traditional defense layers (ASLR, DEP/NX, privilege separation, API isolation, etc.)

If the attacker gets her machine code running in the unikernel environment, it's game over no matter what. The machine code can just directly implement a subset of needed functionality without having to call out to unikernel functions.

In short - this post has a hell of a click bait title but really insufficient evidence to suggest that these are truly "secure".

<comment><USER14> Keep in mind that it's ring 0 inside a VM that contains almost nothing. Really a unikernel is just a process that uses hypercalls instead of system calls. So exploiting a unikernel is no worse than exploiting a user process, and the article explains a few reasons it could be more secure.

But they should definitely add ASLR.

<comment><USER15> Just like an operating-system executes processes, a VMM executes unikernels. An operating system is responsible for randomizing the layout of processes in memory. Shouldn't the actual question here be _" Does my hypervisor implement some mechanism for randomizing the layout of my unikernel?"_

<comment><USER14> I don't think it matters whether it's implemented by the hypervisor or the unikernel since it's all open source. But for compatibility with existing hypervisors/clouds one could imagine a boot loader that loads the main unikernel at a random address, sets up page tables with NX, and then makes a one-way transition to ring 3 so that the page tables cannot be modified.

<comment><USER15> > one could imagine a boot loader that loads the main unikernel at a random > address, sets up page tables with NX, and then makes a one-way transition to > ring 3

True - I suppose I'm trying to hold onto the "kernel:hypervisor :: process:unikernel" analogy here for no good reason. Following it suggested that it might be the hypervisor's responsibility.

</comment></comment></comment></comment></comment><comment><USER16> The argument that something _IS_ secure is somehow supported by a whole lot of hypotheticals of the form "we could do $X and that would be secure if someone also did $Y".

So say it how it is: _unikernels COULD be secure if all this work that needs to be done and we haven 't done was done...maybe_

<comment><USER14> That's par for the course. Unikernel people talk about VMs that use megabytes of RAM while cloud providers only provide gigabytes. Unikernel people talk about spawning VMs in tens of milliseconds while clouds take tens of seconds.

</comment></comment><comment><USER17> Hypothetically, if there were a buffer overflow in a unikernel process, wouldn't it potentially give the exploit full-system access, whereas a normal operating system would detect the out-of-bounds memory access and kill the process? I'm sorry if this is an ignorant question.

<comment><USER18> I could be wrong, but I think this is what Memory Management Units are for, on processor chips. It's one major differentiator between application processors and more embedded ones like Cortex-M or ATMega MCUs, which typically can't run complex modern operating systems. A lot of those chips have a simpler Memory Protection Unit that does basic enforcement of permissions like read+execute, read+write, etc, but they lack the ability to partition memory virtually between a large number of potential 'owners.'

I think - I'm still learning about this embedded stuff.

<comment> vertex-four The point is that once you're doing that, and implementing communication between all your separate owners (which map pretty precisely to a reasonable definition of "processes")... you've just implemented another operating system, not a unikernel.

</comment></comment></comment><comment><USER19> In addition to the blog post, there's an interesting discussion on Github that happened before the blog post was published: [https://github.com/Unikernel- Systems/unikernel.org/pull/45](https://github.com/Unikernel- Systems/unikernel.org/pull/45)

<comment><USER20> Excellent discussion. I'm not knowledgeable enough in Linux internals to know whether the ring0 versus ring3 criticism is warranted. Is it just a matter of if/when an attacker achieves escalated privileges they will have far more attack surface on ring0?

<comment><USER21> There is quite a difference.

Ring 3 is userspace, you can't interact with hardware or the operating system or anything not in Ring 3 directly.

Ring 0 is everything. There are no restrictions and nothing stops you from writing "Ahahah You didn't say the magic word!" over your entire memory until the CPU crashes.

Having root on a linux kernel is heavily restricted compared to this and still runs in Ring 3 like all other userspace code.

As root, you still have to run the kernel. As Ring 0, you can replace the kernel. Or run your own OS.

<comment><USER22> Access to ring 0 on a traditional OS is indeed usually "game over".

In the case of a unikernel deployed on a hypervisor this is not the case, since there is not much else in ring 0 that you wouldn't already have access to from ring 3. Conceptually you can think of the hypervisor as "kernel space" and anything inside the unikernel as "userspace".

There _are_ advantages to running the unikernel solely in ring 3 (eg. immutable page tables) however this is not a requirement for security.

<comment><USER21> I still see it as worse than a normal application being compromised.

When Ring 0 is compromised, there is no alert or anything to protect the app from compromise. If there is an exploit, it's game over.

However, in Ring 3 and a normal kernel, you get various protections that allow the kernel to recognize some attacks and shutdown the application immediately or even shutdown the kernel.

This prevents a compromised app from running to some extend.

A unikernel cannot do this. If the app is compromised and I don't notice and don't restart it...

Even worse, the attacker could use it as leverage to infect other unikernel based instances of the app to gain some permanence against restarts by simply reinfecting when an instance goes down.

The unikernel is not userspace, not even conceptually. The hpyervisor will not shutdown the app unless it executes illegal instructions. The kernel will shutdown misbehaving programs more easily.

<comment><USER22> > A unikernel cannot do this. If the app is compromised and I don't notice and > don't restart it...

I disagree. There's no reason such mitigations (not sure what exactly you're referring to) can't be implemented by the monitor process (ukvm in the Solo5/ukvm model).

I'd also argue that a _normal_ kernel does not do any integrity checks on the code running in a user process, so the model is exactly the same.

> Even worse, the attacker could use it as leverage to infect other unikernel > based instances of the app to gain some permanence against restarts by > simply reinfecting when an instance goes down.

For that they'd need to break out of the virtual machine and into the hypervisor / monitor. Which is by no means impossible, but with careful design of unikernel-specific monitors can be much reduced. Of course, I'm by no means suggesting you should back your unikernels with a monitor along the lines of QEMU :-)

<comment><USER21> 1) You are in _Ring 0_. There is _no_ defense unless you reimplement a normal Kernel to run a process in Ring 3 along with the monitoring process and capabilities management... etc

2) No, the attacker is most likely there because of some bug in the app, once in the network, it becomes harder to stop the attacker infecting other instances.

3) Hypervisors are not perfect. There are known instances of people infecting the host through the hypervisor.

<comment><USER22> 1) Virtualized Ring 0 != Ring 0. See section 24.6 "VM-execution control fields" of the Intel SDM for details of the controls a hypervisor can use to modify guest behaviour.

2) The same applies to any application, not just unikernels.

3) I completely agree.

<comment><USER21> 1) You are still on _a_ Ring 0. On a normal operating system, an exploited app has a limited action range, depending on the system settings. A lot of exploits simply do not work because the operating system kills the process. On Ring 0, even virtualized, all these protections do not work. You have full control within the VM and you can't have some process within the VM to check this as it is equally vulnerable.

2) Yes but Unikernels do not provide special protection against this either.

<comment><USER22> > On a normal operating system, an exploited app has a limited action range

Minor point, but this seems to be a bit lost in the discussion: Generally 1 unikernel == 1 VM (or, virtualization-backed sandbox, the use of "virtual machine" brings too much baggage with it) == 1 application.

So, the attack scope for the class of attacks we're debating is equally limited to a single application, just like on a normal operating system.

<comment><USER21> Not quite.

When you write an exploit for a normal operating system application, you can't, for example, just write your payload into data memory and start executing it. You can't jump to the address of an array and have the CPU execute it's contents.

On a unikernel this sort of thing becomes trivial since everything is Ring 0 and all protections can be trivially disabled.

You _can_ just write your payload into any arbitrary data field and your exploit only needs to jump to it, even with address randomization this can be exploited (ASLR and similar techniques do not prevent exploits, only make them harder)

The exploiting just becomes a whole lot easier.

It's not even remotely more secure than Ring 3 code running on a kernel that has strict capability enforcement.

<comment><USER22> > On a unikernel this sort of thing becomes trivial since everything is Ring 0 > and all protections can be trivially disabled.

If the hypervisor sets the relevant VMCS control fields for the unikernel to cause a VMEXIT on (for example) a load of CR3 and any EPT violations _and_ sets up the guest with a static set of read-only and executable (or in fact, with EPT you could even do execute-only) pages then there is no way the unikernel can disable these protections.

Having said that, I'm not arguing that running unikernels in Ring 0 is the best approach for security, just that it's not impossibly insecure.

With ukvm we're also looking into running all of the unikernel in (virtualized) Ring 3 with _nothing_ running in Ring 0. However, this needs more experimentation since with x86 you can't (for example) easily handle legitimate exceptions (e.g. divide by zero) from Ring 3.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> Unikernels are not that new. CMS running on VM has existed since the 1960s, with CMS being the unikernel (actually, a unitasking OS about as complex as MS-DOS) and VM being what's now called a hypervisor: Something which multiplexes hardware, but provides no APIs, such that VM guests think they're running alone on bare hardware.

(VM can even run VM as a guest, recursively, which is useful for developing the newer version of VM on a machine other people are using for other work.)

Therefore, we can evaluate these claims by asking what we know about security breaches on VM/CMS systems.

<comment><USER24> _Something which multiplexes hardware, but provides no APIs, such that VM guests think they 're running alone on bare hardware._

There is what amounts to an "API". The virtualized software thinks it's talking directly to hardware, so the API is just an emulation of that hardware. Since controlling hardware is almost invariably messier than doing system calls, the API is actually more complex.

 _Therefore, we can evaluate these claims by asking what we know about security breaches on VM /CMS systems._

Here's an HN post I wrote a few years ago, about VM exploits: [https://news.ycombinator.com/item?id=9241807](https://news.ycombinator.com/item?id=9241807)

Plenty of exploits to be found, many of which were related to emulation of "I/O channel programs", which are, essentially, System/370 I/O "hardware".

<comment><USER23> > There is what amounts to an "API". The virtualized software thinks it's > talking directly to hardware, so the API is just an emulation of that > hardware. Since controlling hardware is almost invariably messier than doing > system calls, the API is actually more complex.

Nobody said a hypervisor was completely trivial, but just to be clear, a pure hypervisor wouldn't "emulate" any hardware except what was physically present on the system. The line between "virtual machine" and "hypervisor" and "emulator" are blurry enough as it is, and I'd like to be clear about what the subject of _this_ little thread is.

> Here's an HN post I wrote a few years ago, about VM exploits: > [https://news.ycombinator.com/item?id=9241807](https://news.ycombinator.com/item?id=9241807)

> Plenty of exploits to be found, many of which were related to emulation of > "I/O channel programs", which are, essentially, System/370 I/O "hardware".

Very interesting. Thank you.

</comment></comment></comment><comment><USER25> _" Unikernels have no shells. Most attacks I've seen invoke /bin/sh to modify the system they are attacking. Without a shell the attacker doesn't have this opportunity. This forces the attacker to use machine code to subvert the system, decreasing the likelihood of succeeding with the attack."_

Timmy the software developer and his many years of forensic analysis have led him to believe that you need a shell to root something. Literally the entire page's takeaway about security is "It's hard to use, so it's secure!"

</comment><comment><USER26> One thing that I never understand when I read articles like this ( _especially_ this article) is that the "security improvements" that are mentioned are entirely related to there being no userspace (you don't need a shell or syscalls if you don't have a userspace).

But the whole point of userspace is to provide privilege separation between the kernel and userspace. In unikernels everything is in the kernel, and you can freely mutate in-kernel state without any segmentation violations. In other words, of course there are no syscalls when there is no separation between user code and the kernel ("no syscalls" is the description of a unikernel). So, what is the tangible security benefit?

What I want to know is how do you protect against in-kernel ROP? Or hell, just plain old-fashioned stack overflows? The ASLR mentioned is not really useful because it's only on-recompile (Linux's ASLR is on-execution). The only experience I've had with writing shell code was messing around with [https://microcorruption.com/](https://microcorruption.com/) for a few evenings, and even _I_ know that putting everything into the same address space is just asking for trouble (of course you can mitigate it, but praising the premise as a feat of security seems to be missing the point to me).

Maybe I'm just massively misinformed, but I simply don't see how someone can proclaim that "unikernels are secure" by just re-stating the premise as the justification for their security (and then following up with a bunch of hypotheticals).

</comment><comment><USER27> A unikernel is running a single process in a single address space. So yes, if you compromise the app you compromise the whole system but the whole system is the app.

<comment><USER28> That's not entirely true in practice. I'm currently playing with rump kernels deployed on top of seL4's hypervisor to give my platform the security posture of a unikernel inside the security posture of seL4 VM isolation.

You could potentially compromise the rump kernel, but you still wouldn't be able to break out of the VM's isolation context.

<comment><USER21> The app is still compromised.

On top of that, you didn't get to reap the benefits of any of the protections you get from a proper Kernel like Ring 3 execution, NX bits on pages, guard pages on the stack, etc.

</comment></comment></comment><comment><USER29> I don't really like the argument that something is 'secure' because it is not vulnerable in the same ways that an alternative is. I think this is why I like talking about encryption so much. It's possible to mathematically prove the security of encryption algorithms, and all that's really left to pick apart is the implementation, politics and impact.

<comment> vertex-four Ehh... you can often prove that X algorithm is not susceptible to A, B or C attacks, but you cannot usually prove that the algorithm is "secure" in a fundamental sense.

<comment><USER30> [https://en.wikipedia.org/wiki/Provable_security](https://en.wikipedia.org/wiki/Provable_security)

You can prove that it's secure in that the _algorithm itself_ does not leak information.

<comment><USER31> With some exceptions, those proofs make assumptions about their primitives like having block ciphers be "unpredictable permutations" or having hash functions be "random oracles". These proofs also make assumptions that information doesn't leak in other ways (like BEAST, heartbleed, timing attacks, poor entropy sources, etc).

In other words, those proofs don't have as much real-world significance as you'd like.

</comment></comment></comment></comment><comment><USER4> > _Unikernels have no shells. Most attacks I've seen invoke /bin/sh to modify > the system they are attacking. Without a shell the attacker doesn't have > this opportunity. This forces the attacker to use machine code to subvert > the system, decreasing the likelihood of succeeding with the attack._

This argument is completely incoherent.

<comment><USER32> And, while this is a more minor rebuttal, it's still worth saying: _it 's totally incorrect_. Modern exploits (for definitions of "modern" meaning "written after 1999") do not care if you have a shell on your system.

The author has presumably confused the concept of a POC, which is an exploit reduced and simplified for the consumption and understanding of laypeople, with that of a real exploit.

<comment><USER22> As one the early users[1] guilty of using the "there is no shell" argument for unikernel security, I agree with what you say. I would rephrase the argument as "there is no fork()/exec()", meaning that a unikernel cannot spawn a new process.

A unikernel application which only executes native code[2], combined with a hypervisor / hardware that enforces immutable page tables and NX, AFAICT leaves ROP/JOP as the sole remaining attack vector for RCE. Further, each deployment of the application should be done via a new build (or at least re- link), which can employ the build-time ASLR Per mentions to mitigate ROP/JOP attacks.

I'd be interested in your thoughts on what other relevant attack vectors I've not thought of that would allow for a persistent compromise of a unikernel. Feel free to discuss here or on the devel.unikernel.org forum thread[3].

[1] Page 4 in this whitepaper from 2015: [https://wiki.xenproject.org/images/3/34/XenProject_Unikernel...](https://wiki.xenproject.org/images/3/34/XenProject_Unikernel_Whitepaper_2015_FINAL.pdf)

[2] Does not contain a JIT or interpreter able to "eval()" new code.

[3] [https://devel.unikernel.org/t/unikernels-are-secure-here- is-...](https://devel.unikernel.org/t/unikernels-are-secure-here-is-why/258/2)

<comment><USER32> What difference does it make if there's no fork/exec? Back in 1999 we had MOSDEF and CORE IMPACT, both of which used staged loaders to boot up a language runtime in a remote process after compromising it with a stack overflow. In a broader sense this is stuff that viruses had been doing for about 8 years prior to that.

Only executing native code is no defense at all. You're not even stopping attackers from the '90s like that.

ROP is only a hardship until exploit code can find a way to allocate executable memory or hook the program's own dynamic execution (note: this is not necessarily a "JIT" or "eval") capabilities. ASLR only matters when exploits can't find infoleaks.

Really, what you're describing here is the browser security model. When staffed by the largest, best security teams in the world, the browser security model almost works.

<comment><USER22> > Back in 1999 we had MOSDEF and CORE IMPACT (...)

I'm not familiar with these. Googling "MOSDEF attack" suggests Massive Attack songs and "CORE IMPACT" various products by Core Security, I presume you're referring to neither? :-)

> Only executing native code is no defense at all. You're not even stopping > attackers from the '90s like that.

> ROP is only a hardship until exploit code can find a way to allocate > executable memory or hook the program's own dynamic execution (...)

Only executing native code _loaded at deployment time_ , i.e. presumably from a trusted source. What I meant by "immutable page tables" is that after loading the unikernel image the set of executable pages is fixed, and all of those are read only. This is not something current unikernels do, but that's more due to lack of development time rather than any inherent implementation complexity.

If there is no way for the exploit code to ask the hypervisor for new executable pages or overwrite existing ones then the amount of damage it can do and its ability to persist in the running system is greatly reduced.

> Really, what you're describing here is the browser security model. When > staffed by the largest, best security teams in the world, the browser > security model almost works.

It's similar but not the same. The browser security model breaks down in a large part due to exposing way too many APIs, most of which are too complex to sensibly audit. Linux system calls have a similar problem, which is why you have to hand-craft things like seccomp profiles to match your particular application.

Unikernels (as used to implement network services) lend themselves extremely well to running on top of a well defined API / sandbox boundary, designed with security in mind. Again, we're not there yet, but the steps we need to explore in this direction are fairly clear.

<comment><USER33> MOSDEF: [https://www.blackhat.com/presentations/bh-federal-03/bh- fed-...](https://www.blackhat.com/presentations/bh-federal-03/bh- fed-03-aitel.pdf)

Core IMPACT: [http://seclists.org/pen- test/2006/May/9](http://seclists.org/pen-test/2006/May/9)

</comment></comment></comment></comment></comment></comment><comment><USER34> "No system calls"

Yeah, they're direct function calls now. How exactly is that more secure? The author's right that many traditional exploit paths are gone, but only because they've been replaced by _even easier_ ones.

<comment><USER35> Because you don't know how to call the functions, as explained in the article. To call a function, you need to know its address among other things. And you don't, since the address was decided at random at build time (or even boot time in some systems).

<comment><USER34> There are other ways to find functions besides knowing their addresses a priori.

<comment><USER35> How is this done?

I think kernels try not to leak the address of system calls at run time, and if they are scattered around in a 64bit address space they are tough to search for. Educate me!

<comment><USER36> I have no idea, but couldn't you use some part of the software you just compromised that makes syscalls?

<comment><USER35> There are no syscalls as the fine article explains.

<comment><USER35> Ah, wait, I mis-read your comment and it's too late to edit mine. Yes, that sounds plausible, and particularly if you have the source code, which you do for many common servers.

</comment></comment></comment></comment></comment></comment></comment><comment><USER37> The real problem for unikernels is that they are effectively irrelevant until the major clouds provide millisecond boot times along with appropriate pricing models that charge for execution on a millisecond level basis.

Developers love to write code, but unless unikernel developers start speaking up instead of writing code, the major clouds won't get on board and provide the needed fast boot times plus pricing, which makes all this unikernel code not a lot more than interesting personal / academic projects.

Questions of unikernel security are certainly academic if the cloud infrastructure doesn't run them in the most effective manner.

<comment><USER38> Why are millisecond bit times necessary? Linux doesn't boot in a millisecond...

<comment><USER37> Because you can then build single function unikernels that do one thing very fast then disappear from RAM.

The point being that docker is actually a really clunky thing that is reinventing the virtual server ecosystem within the OS which is pointless.

Serverless systems are better implemented as unikernels than docker images.

Unikernels make it possible to boot an entire OS in milliseconds, service an inbound web request, then disappear.

<comment><USER39> What's the use case for booting an entire OS to service a request?

<comment><USER40> when the OS is just some library functions statically compiled in and the entire binary is a few megabytes that you can load directly into memory, why not?

</comment></comment></comment></comment></comment><comment><USER41> Hard to take claims of security seriously for untyped languages which are not provably correct and lack a denotational semantics. Let's start by provably not compiling buffer overflows and memory overreads considering those are the vast majority of RCE and privilege escalation.

<comment><USER9> C++ is strongly typed. I believe there are frameworks that will give you denotational semantics in C++.

It shouldn't surprise anyone that feature X is available in C++. But I acknowledge there are tons of shotguns strewn around everywhere in C++ so you can blow your feet off.

<comment><USER42> C++ is not "strongly typed" when compared to almost any other statically-typed language, e.g. Ada, OCaml, Haskell or Rust. This is a big part of why it is so insecure.

</comment></comment></comment><comment><USER43> > There are two aspects of unikernel security. There are two aspects of > unikernel security. One is the vector into the VM and the other is the > vector from the VM into the hypervisor.

The "vector into the VM" might not be as obvious. For example, in a network security contest in college I compromised the source repository of the server to give my team an advantage and won. That was before git it was just a folder on the server. Others argued it wasn't fair but the instructor sided with me since that's a plausible scenario in real life.

There also tempest-like attacks for extracting private keys and such, so it's there at also at least the 3rd vector - from VM to the hardware as well. And forth from VM to the network (but I guess these can be subsumed in the "to the hypervisor" case).

</comment><comment><USER44> So now the hypervisor is ring0, the cloud provider is the OS, and the OS is the app. IP is the IPC and the Internet is the IPC bus.

I suppose the hypervisor is more minimal and secure. Tenenbaum, thou art avenged.

</comment><comment><USER45> The intro video is somewhat confusing - it indicates that they're secure but if that they're "harder to attack" and says if they are compromised they can be restored. Also, he said "in the future, I believe unikernels will be more or less unbreakable"

I think you could describe that as "more secure" or perhaps more generically "safer" rather than "secure."

</comment><comment><USER46> don't unikernels run everything in ring0. if you run everything in ring0 you can't claim not having system calls is a security feature :/

</comment><comment><USER47> And if you run a Linux kernel with a C app as one, for example, it's probably possible to run a shellcode proxy in memory, even if you can't modify the app code, you could ROP if a big enough buffer overflow is possible on the stack, etc.?

</comment><comment><USER48> None of the claims in this have anything to do with the essence of security, they all address the window-dressing of security.

What does it mean for something to be secure? As I see it, for something to be secure, it means that every security invariant holds under all attacker models.

Let's break this down. What's a security invariant, and what's an attacker model?

A security invariant is a statement like "information may only be read by principals authorized to do so" or something similar. The blog post talks about "oh well every exploit I've seen pops a shell with /bin/sh and we don't have /bin/sh so you can't hack it." This attacks the symptom and not the disease. If the attacker is in a position to run /bin/sh you are already at a disadvantage, the attacker was previously going to break your security invariant by spawning a shell and then copying out your secrets. They could instead just use their code execution to read the secrets directly, ala heartbleed, if they are in the same address space.

An attacker model describes the attacker, their motivations/goals, and capabilities. For example, what if the attacker wanted to take your unikernel enabled app and repurpose it into an e-mail spam bot? Well, there isn't a writeable FS and there isn't the ability to exec stuff, so the old model of "copy some files up and run them" won't work. However, is there executable memory in general? Can the application allocate existing executable memory? If the application is, or involves, for example a modern JavaScript interpreter, then it has to be able to do this in some capacity. So now the attacker modifies their methods so that their goal can be achieved in the constraints of this new system.

There is an argument you can make about sandboxing and principle of least privilege, but that argument transcends unikernels really. Look at the sandboxing and separation strategies used by programs like chrome, vsftpd, and qmail. They (in conjunction with enforcement technologies like seccomp-bpf or selinux) can make the same guarantees about the lack of system calls and least privilege.

I'm pretty sure that the title of this post really should be "unikernels are _obscure_ " because that's the layer of protection you're really getting here.

</comment><comment><USER49> > IncludeOS is a clean-slate unikernel written in C++ with performance and > security in mind.

One of those things doesn't belong there. Guess which?

<comment><USER42> Yes it reads like satire. MirageOS, having been written in OCaml, would have a better claim to being written with security in mind.

</comment></comment><comment><USER50> The article states:

>"Unikernels on the other hand don't have system calls. They only have function calls."

If my program is compiled against glibc functions which wrap actual system calls how does my program work when there is no userland?

Is there a compiler that compiles my program to a unikernel target? Can someone explain how this works?

</comment><comment><USER51> "Secure" and yet they aren't even using a memory safe language such as Rust.

</comment><comment><USER52> Looks to be unikernel is just a RTOS, why the name unikernel then ? Whats the difference with RTOS?

<comment><USER53> A unikernel could be designed as an RTOS, but not all RTOS are unikernels (in fact, I'm not aware that _any_ are). Indeed, QNX, a RTOS, is not implemented using a single address space, nor is your application linked against the kernel and supporting libraries into a unikernel. While it's certainly possible that you could implement an application/unikernel with real-time guarantees, I'm not aware of a specific unikernel implementation that targets that space specifically.

<comment><USER52> Thanks or your kind reply, I use to find difficult to classify between RTOS and unikernels technically.

</comment></comment></comment><comment><USER54> > What we need is this:

> * packet interface for the network

> * a block interface for some storage

> * a serial port to output console data

Some applications need additional devices, such as for example hardware RNG, atomic clocks and/or GPGPU.

</comment><comment><USER55> Why am I reading this "Unicorns"? :D

</comment><comment><USER56> It's secure if and only if there's a formal proof.

<comment><USER57> "Secure" sounds like a binary attribute but it's actually not. A formal proof doesn't save you from errors in the specification. At some point you need trust, the amount of trust needed is inversely proportional to the security.

<comment><USER41> Without a formal proof there is no measure of correctness at all.

<comment><USER57> Lots of passing tests mean nothing to you?

<comment><USER58> When an exploit only needs one edge case not handled right? No, lots of unit tests means nothing. Maybe less than nothing due to the false sense of security they seem to give you.

<comment><USER57> So you trust a software that has had zero testing equally to a software like sqlite that has extensive testing?

</comment></comment></comment></comment></comment></comment><comment><USER59> Generalisations are generalising.

</comment><comment><USER60> Claiming something is secure is more like claiming an over unity perpetual machine</comment>


The Paradox of  Atheoretical Classification [pdf] - <AUTHOR> http://static-curis.ku.dk/portal/files/162415301/Proof_Paradox_of_atheoreticsl_cl.pdf <comment><USER2> This paper is interesting to read, but confusing in my opinion and sort of misled.

I'm not sure what point the author seems to be making about the DSM. They seem to be stating something along the lines of "The DSM isn't successful because it's atheoretical, it's successful because it adopted a biological theory, and because its emphasis on reliability facilitated sociopolitical control by the psychiatric profession." But later they recognize that the DSM isn't successful, seeming to contradict themselves.

The theory of the DSM goes far beyond biology, being explicitly neo- Kraepelinian and to some extent psychodynamic in nature, although that would probably not be acknowledged by any of the DSM's authors unless you pressed them on it. The success and failure of the DSM has everything to do with sociopolitical factors and the biological and nonbiological tenets of neo- Kraepelinian classification, and not on "atheoretical versus natural" or "scientific versus nonscientific" or "ontological versus nonontological" or "descriptive versus theoretical" or "ontological versus epistemological" or any of those sorts of distinctions.

The DSM adopted Kraepelinian categories and assumptions, shoehorning psychodynamic theories into this framework in some cases, and then further elaborating the system with very biological criteria. It essentially asserts that the major Kraepelinian categories are valid, that mental illness is discretely distinguished from normality or wellness, and that its categories reflect disruptions of biological systems that can be determined by certain patterns of biological observations. It further asserts that reliability is a central feature of classification and assessment. Some of these assumptions have been accepted, cementing its success, but some assumptions have been rejected by the community, leading to the current crisis that the author recognizes. Underlying all of this are sociopolitical factors, such as professional practice conventions, boundaries, and laws, and popular perception, that have both augmented the DSM, but also undermined it by highlighting the political processes underling its continued use.

The question is not whether a classification system is atheoretical or natural, or descriptive versus natural, or ontological versus epistemological, it's what criteria or theoretical principles are used to derive the system. In the case of psychiatric classification, the tension historically, even with the DSM itself, has not been about "atheoretical" versus "natural" systems, it has been about whether classification systems are at the level of behavior, which is proximate to the phenomena of interest and relatively tractable, or biology, which is proximate to the causes of those phenomena, but relatively intractable due to those causes being unknown. It's a bit like trying to classify species, genera, etc. without knowledge of genetics. You can proceed with a biology-based classification system under the assumption that your understanding is close enough, or you can acknowledge that you don't understand it and rigorously classify lifeforms based on what you do understand. Or you can try to do something intermediate. None of these are "natural" or "atheoretical," they're just at different levels of analysis. Another analogy might be found in computer science: do you derive document/file ontologies based on biology, or something like unsupervised AI classification? People like to assume that going down to a lower level of scientific analysis is always better, and it might be, but it might also not be, depending on your goals.

<comment><USER3> Having quite a bit of experience with the DSM since DSM-II, the article gives a fairly coherent history of the document, and is correct that the advent of DSM-III signaled a radical departure from the earlier, and much less useful versions.

The theoretical underpinnings have been an issue in hot debate since the DSM- III was in preparation. The deliberately descriptive nature of the classification has been opposed by many critics who favor a more "casual" medical classification or proponents of other theoretical systems.

Stakeholders in the recent and very prolonged gestation of DSM-5 fell into two main groups, let's call them researchers vs. clinicians, or splitters vs lumpers. The splitters were groups interested in having very specific criteria that sharply distinguished diagnostic categories which of course suits research agendas. OTOH clinicians, aka lumpers, were more interested in the intermediate cases, like typical patients, that don't fit into highly distinct categories at all well.

An alternative scheme was dimensional classification, which runs orthogonally to the standard descriptive schema, inasmuch as behavioral dimensions such as low mood are frequently encountered among many existing disorders. To clinicians this idea had much appeal since it would most usefully reflect symptom-oriented treatment modalities.

Whatever scheme is chosen it will have shortcomings. There is really insufficient information at present to form a basis for any given theoretical approach. It is quite apparent that there are biological, social, physical, political and other phenomena that contribute to development of illness of all kinds, including psychiatric disorders.

In this brief comment it's barely possible to scratch the surface of the concepts and assumptions underlying the idea of "mental illness", however I think the article is discussing issues tangential to those confronting psychiatrists who grapple with management of the very disorderly nature of psychiatric disorders.

The present diagnostic scheme is a practical compromise of many points of view about disorders in general and specific disorders in detail. The DSM is the field's attempt to find a language to discuss the great challenges in understanding and healing very complex situations about which science has only fragments of information.

IMO the relevance of the thousands of "theories" concerning human behavior is yet to be determined. We need to have a great deal more knowledge about the functional connections of the human organism in consideration of the near- infinite range of neural, endocrine and immune system signaling and interaction before it's appropriate to establish meaningful theories in the human behavioral domain.

<comment><USER4> Whenever discussion of the DSM arises, I tend to revert to Ian Hacking's critique of the guide ([http://www.lrb.co.uk/v35/n15/ian-hacking/lost-in-the- forest](http://www.lrb.co.uk/v35/n15/ian-hacking/lost-in-the-forest)).

I'm a big fan of his contributions in the philosophy of science, which perhaps gives his opinion more weight than it should on psychiatric matters (Rewriting the Soul, and Mad Travellers are excellent books).

Is this criticism mistaken though?

<comment><USER3> Unfortunately I'm not familiar with Hacking's piece, and I'll be very interested in reading it. On a first run-through many of the expressed doubts and concerns have been aired extensively in the 19 years between publishing DSM-IV and DSM-5.

As I said a repeating theme is the tension between what researchers want and what's useful in clinical practice. With a foot in both camps, I have sympathies with both points of view. Perhaps no one set of criteria is universally suitable.

As an non-psychiatric example I've been interested in the body's regulation of calcium balance. When it's negative calcium is lost and results in thinning bones, in full form it's osteoporosis, a disabling condition to be sure. One aspect is calcium loss through the kidneys. The measure is 24hr calcium excretion in the urine. The point is for clinical purposes 200mg/24hr is significant, but researchers studying the problem would probably select 250 or 300mg/24hr because it defines a more homogeneous group.

IOW the cutoff point for having or not having a disorder is soft, indistinct and somewhat arbitrary. If a person loses 199mg/24 hours does that not count as a potential problem?

As Hacking says, the DSM is a work in progress. There are many messy issues in real world practice of medicine including psychiatry. The DSM is a composite of a hundred philosophies, I too have high regard for some philosophers, but the DSM is a philosophical nightmare by any measure.

I've long since memorized parts of the DSM, and I can recite those in my sleep, but always take it, like all science literature with ample quantities of salt.

The saying goes if you like sausage, don't watch how they make it. The DSM is like sausage, and politics, a very messy production. But for all its quirks, and there are many, there is really nothing better for its main purposes. As long as it's not always taken literally, and with healthy doses of clear thinking, it is sometimes very useful, and sometimes not.

Thanks for bringing up your excellent question. I don't think I've answered it very well. A thousand different criticisms would be easy to conjure, but kind of a bottom is that for all the pot shots no one has come up with with anything that is even close to being as applicable in so many different settings.</comment></comment></comment></comment>


Show HN: A realtime node-based audio synth based on LLVM - <AUTHOR> https://github.com/monadgroup/axiom <comment><AUTHOR> Hey friends!

This is a project I've been working on since the start of the year. We've just released 0.4.0, so I figured now would be a nice time to start making it a bit more public. There's a bunch of interesting tech under the hood which I thought you all would definitely be interested in :)

Axiom's a project that grew out of my third try at building a realtime software synthesizer for 64k intros in the demoscene. You can't really fit an mp3 file in an executable that small and expect for it to sound any good, so instead we synthesize the audio and play it in realtime. A few other groups have written synthesizers for 4k and 64k productions, however I built this for two reasons: I wanted to make one myself, and I wanted to try some interesting things with combining node graphs and basic scripting. At some point, however, I realized that this could actually be a really useful tool for any musician to have, since it really flips things on its head and allows much more control than just stringing together a bunch of plugins (the question is, of course, do people who make music _want_ this control - I'm not sure on the answer yet).

Technology-wise, Axiom compiles 'node surfaces' with LLVM (no interpreters here, the code has to run comfortably 44100 times per second!). The editor, written in C++ with Qt, builds a MIR and passes it into the compiler, written in Rust. This was my first large project in C++ and first project in Rust... ultimately I think the Rust learning curve has definitely been worth it, as it's by far the stablest part of the program!

Ultimately I'm hoping to somehow be able to turn this into a real product, possibly by offering what you see as the core open-source software and then building on it, into something like a DAW or plugin for procedural audio in game engines (which a few people have suggested to me, and I think would be a really cool application of the technology!).

Check it out, let me know what you think (either here, or shoot me an email, chat on twitter, etc), ask questions, build something cool, have fun!

<comment><USER2> I suppose that you are familiar wuth analog modular synthesizers. There is a demand for these, even though they become very expensive toys fast. But musicians seem to like the flexibility and room for experiments that they allow. Even software simulations of these synths are pretty successful. VCV Rack ([http://www.vcvrack.com](http://www.vcvrack.com)) is a recent open source emulation of eurorack synthesizers that has found a following fast.

If you are interested in providing procedural audio for games, you should take a quick look at what WWise provides in that area. I have not had time to do that myself, but from what I have seen it provides a lot of features for controlling sound and music based on the current game situation. It is also a pretty expensive package.

Edit: corrected link. Thank you striking!

<comment><USER3> (the link is actually [https://www.vcvrack.com](https://www.vcvrack.com))

</comment></comment></comment><comment><USER4> The VSTi support is pretty sweet-it pretty much changes this sort of thing from toy to tool.

</comment><comment><USER5> Awesome, I've always wanted to make something like this myself but never came around to do it!

It would be really neat if someone combined this with a very simple sequencer/tracker to create and manipulate tunes, which could then be dropped in (sequencer + synthesizer) directly into projects. It could be a quick and easy way to add music to small-scale retro game projects, for example.

</comment><comment><USER6> Looks really cool, and similar to Audulus [http://audulus.com/](http://audulus.com/)

<comment><AUTHOR> Yes, this was one of the initial inspirations for the design of Axiom! I never actually had the chance to play with it though... would be quite interested in learning how it works.

</comment></comment><comment><USER7> Looks cool, looking forward to playing around with it!

If it is compiling, can it also export code/libraries that can be embedded in other projects, or is the way to go to embed the entire thing? Since you mention demos as a target group I'd guess the first, but it isn't entirely clear.

<comment><AUTHOR> Yep, that was one of the original ideas with using LLVM. The actual runtime that's needed is pretty small and the code optimizes well, so the output ends up being very close to if you'd written the code in, say C++, yourself.

But that said, I haven't actually gotten to writing the 'exporter' yet (up to this point I've mostly been focused on usability and stability), so I can understand that it's not entirely clear.

</comment></comment><comment><USER8> Overall looks pretty neat. I'm a big fan of dark themes, but I think this one takes it a bit too far. I'm having trouble reading the text which doesn't contrast well against the background. Consider lightening some of the elements.

<comment><AUTHOR> Yeah, you're not wrong that it's pretty dark. I have done a bit of work recently on lightening up (it was even darker before!), but I'll definitely look at brightening it further in the near future.</comment></comment>


Ten Tech Trends to Ignore--According to BusinessWeek - <AUTHOR> http://images.businessweek.com/ss/08/03/0305_viewpoint/index_01.htm

<comment><USER2> Most of these are insane. Ignore OSS, Apple, and Vitrual servers? I'm sorry but "it doesn't run quicken multi user mode" is not a reason for me to not buy anything Apple. Right now I'm using an open source browser, running on an open source operating system. The software that serves our webpages is open source, as is the MTA, email client, editor, IRC client, and instant messaging client. Virtual servers make sense now in a lot of cases.

</comment><comment><USER3> Wow, this is worse than the start-up money saving tips. They're right about social-farceware though.

</comment><comment><AUTHOR> I posted it because while the comments made by BusinessWeek are self- contradictory and somewhat resigned to a fate of Microsoft-dominated software forever, they do give some insight into problems that startups could help solve, as seen from the standpoint of business users.</comment>


Linux kernel root-level exploit leveraging three previous vulnerabilities - <AUTHOR> http://marc.info/?l=full-disclosure&m=129175358621826&w=2

<comment><USER2> Did not work on a server running Debian Lenny with 2.6.26-2-amd64. Worked fine on Ubuntu Server 10.10 with 2.6.35-22-generic-pae though (got root shell).

The comments mention that the exploit for CVE-2010-3850 is limited in regard to Slackware, Debian and Red Hat "in the interest of public safety". Interesting.

</comment><comment><USER3> Note to everyone here: the interesting issue is CVE-2010-4258 (write a NULL to arbitrary memory on OOPS). The other two issues have been deliberately chosen to be exotic and hard to exploit, but

        * However, the important issue, CVE-2010-4258, affects everyone, and it would
        * be trivial to find an unpatched DoS under KERNEL_DS and write a slightly
        * more sophisticated version of this that doesn't have the roadblocks I put in
        * to prevent abuse by script kiddies.

So no, if this happened not to work on your box, you'll still want to upgrade.

[EDIT: this was also pointed out by bdonlan, <http://news.ycombinator.com/item?id=1981738>]

</comment><comment><USER4> Information on kernel OOPS for others who were not familiar with the term. <http://en.wikipedia.org/wiki/Linux_kernel_oops>

Exploit didn't work on my Ubuntu 10.04.1 LTS. It does say the exploits are fixed on Ubuntu, but the socket(PF_ECONET,...) call not working stopped it on my box.

</comment><comment><USER5> This didn't work on an Arch linux (x86) box. I think I did pacman -Syu last weekend, so it's reasonably up to date.

It also doesn't work on my Slackware server, which has a pretty heavily modified 188.8.131.52 kernel.

In the context of the other comments, does this mean that a lack of a software monoculture keeps these sorts of exploits from damaging the entire population of linux machines?

<comment><USER6> The exploit is specifically designed to only work on a small subset of kernel builds, as indicated in the header:

       * In the interest of public safety, this exploit was specifically designed to
       * be limited:
       *
       *  * The particular symbols I resolve are not exported   on Slackware or Debian
       *  * Red Hat does not support Econet by default
       *  * CVE-2010-3849 and CVE-2010-3850 have both been patched by Ubuntu and
       *    Debian
       *
       * However, the important issue, CVE-2010-4258, affects everyone, and it would
       * be trivial to find an unpatched DoS under KERNEL_DS and write a slightly
       * more sophisticated version of this that doesn't have the roadblocks I put in
       * to prevent abuse by script kiddies.

<comment><USER7> What a very responsible way of releasing this.

Not that it would take a competent hacker more than a few minutes to figure out how to disable the blocks but at least this rules out a chunk of the 'l33t' crowd from having their way, which just might buy someone enough time to get it patched.

</comment></comment></comment><comment><USER8> Any countermeasures, besides not using a kernel supporting the Econet protocol? I.e., does there exist a fix for the first CVE addressed in the exploit's comment?

</comment><comment><USER9> Worked on Ubuntu 10.10 Meerkat. Gotta love it. Instant root.

</comment><comment><USER10> Failed on mine

        tzury@precision:/tmp$ uname -a
        Linux precision 2.6.32-26-generic #48-Ubuntu SMP Wed Nov 24 10:14:11 UTC 2010 x86_64 GNU/Linux
        tzury@precision:/tmp$ gcc nelson.c
        tzury@precision:/tmp$ ./a.out
         [*] Resolving kernel addresses...
         [+] Resolved econet_ioctl to 0xffffffffa00705d0
         [+] Resolved econet_ops to 0xffffffffa00706c0
         [+] Resolved commit_creds to 0xffffffff8108aed0
         [+] Resolved prepare_kernel_cred to 0xffffffff8108b2b0
        [*] Calculating target...
        [*] Triggering payload...
        [*] Exploit failed to get root.

<comment><USER11> Read the header of the C program.

<comment><USER10> Perhaps that is because I am well patched.

Anyway, 2.6.32 <= 2.6.37 (my kernel).

Beside, people are here have reported about their Ubuntu boxes which this exploit showed some success at there

        tzury@precision:/tmp$ uname -a
        Linux precision 2.6.32-26-generic #48-Ubuntu SMP Wed Nov 24 10:14:11 UTC 2010 x86_64 GNU/Linux
        tzury@precision:/tmp$ cat /etc/lsb-release
        DISTRIB_ID=Ubuntu
        DISTRIB_RELEASE=10.04
        DISTRIB_CODENAME=lucid
        DISTRIB_DESCRIPTION="Ubuntu 10.04.1 LTS"
        tzury@precision:/tmp$ gcc full-nelson.c -o full-nelson
        tzury@precision:/tmp$ ./full-nelson
        [*] Resolving kernel addresses...
         [+] Resolved econet_ioctl to 0xffffffffa01815d0
         [+] Resolved econet_ops to 0xffffffffa01816c0
         [+] Resolved commit_creds to 0xffffffff8108aed0
         [+] Resolved prepare_kernel_cred to 0xffffffff8108b2b0
        [*] Calculating target...
        [*] Triggering payload...
        [*] Exploit failed to get root.

<comment><USER12> The point was that the comment in the header of the program clearly says:

      * In the interest of public safety, this exploit was specifically designed to
      * be limited:
      *
      *  * The particular symbols I resolve are not exported on Slackware or Debian
      *  * Red Hat does not support Econet by default
      *  * CVE-2010-3849 and CVE-2010-3850 have both been patched by Ubuntu and
      *    Debian</comment></comment></comment></comment>


White People Do Good Things for One Another, and That's Bad for Hiring - <AUTHOR> http://blogs.hbr.org/2014/01/white-people-do-good-things-for-one-another-and-thats-bad-for-hiring/

<comment><USER2> Really? This article talks about the author's study on what white people are doing wrong, but neglects to say if she has any data from any other ethnicity.

Also, what she says people are doing wrong is exactly what job coaches encourage job searchers to do when they advocate networking and finding the "hidden job" market.</comment>


Tracking users' IPv6 capability using Google Analytics - <AUTHOR> http://labs.apnic.net/

<comment><AUTHOR> This was shown off at the 19th UK Network Operators' Forum Meeting today, and it's pretty awesome once you've got it installed. <http://test4.vyncke.org/testv6/> is a similar tool which doesn't use Google Analytics.</comment>


Password-less login - <AUTHOR> https://medium.com/findworkco/password-less-login-df0354c3f3ee#.gutdzrjjj <comment><USER2> > _Claim: If someone has access to email account, then they can login._

> _Rebuttal: This is possible in a password-ful login setup via the forgot > password flow. Sometimes there are additional "security questions" but this > is typically easily found information._

The difference here is that if/when someone uses their (unauthorized) access to my e-mail account to reset the password for this service, I will notice the next time I attempt to log in.

In an ideal world, one could _prevent_ another from gaining access to an account, service, etc. When you can't prevent something, the next best thing is _detection_. Here, you've just removed the ability for a user to detect that their account is compromised -- and worse, you're trying to spin it like it's a good thing.

Also, greylisting.

Also, what if I wanted to log in to my account from my phone or a mobile device? I choose not to receive e-mail on my phone (only alerts/notifications) and I'm certainly not the only one.

It sounds like someone pitched this idea at a meeting ("Hey, I know! No passwords!") and the next 10 minutes was spent rationalizing all its problems away before declaring it as the one true solution.

<comment><USER3> >The difference here is that if/when someone uses their (unauthorized) access to my e-mail account to reset the password for this service, I will notice the next time I attempt to log in.

I am assuming the indicator would be an email from a service stating password reset but if the person has access to your email account, the obvious thing to do would be delete such an email. There is no difference.

Passwordless login is basically piggy backing on the security of the email account. You'd have to login to a site anyway but you are just logging in to your email which is assumed to be protected better.

<comment><USER4> I think OP meant that he will clearly realize if someone used his email account to reset his password because next time he tries to log in his old password will no longer work. However with passwordless authentication, someone with access to your email account could issue your account for potentially a long period of time without you noticing. You would still be under the impression that your account is secure.

</comment></comment></comment><comment><USER5> Con: Greylisting.

My primary email uses greylisting to combat spam. This means that if we receive a mail from an unfamiliar mail server, it's getting an error message saying the mail can not be delivered at the moment, and to come back later. Properly configured servers try again several minutes later. Spam bots seldom try again, so it works well.

I can see how greylisting and tokens that expire quickly can be a problem. Particularly if you have multiple servers for outgoing mails, so that the second mail attempt may come from another IP than the first.

<comment><USER6> I'd say that this is a con for graylisting, and not for passwordless access.

<comment><USER7> Or at least, for both.

</comment></comment></comment><comment><USER8> > You can't leak passwords if you don't store passwords.

That's exactly why you only store password hashes in the DB. Come on, this is a solved problem!

> Pro: less implementation effort

Sure. But how much of your app's total dev effort is it? Nothing.

I hate the UX of having to log in by email.

<comment><USER9> >> You can't leak passwords if you don't store passwords.

> That's exactly why you only store password hashes in the DB. Come on, this > is a solved problem!

Isn't leaking hashes dangerous for the users' privacy though (I'm not well- versed in security, so sorry if n00b question)?

<comment><USER10> Not if you salt and choose a strong hash algorithm. Salting is what keeps a leaked hash from hurting a user's security

<comment><USER9> Though if I have the user name and the salted hash and also access to the service providers system, can't I use those to initiate a session? I mean getting the cleartext password allows me to start a session through the UI and also try to penetrate the user's other accounts elsewhere (maybe they reused the password), but if I have the salted hash and access to the sytem, I'm still able to get a session there, no?

<comment><USER10> Salting is to cover password reuse across services. If you already have the keys to the kingdom for a service you can almost certainly access a user's session

</comment></comment></comment></comment></comment><comment><USER11> This implementation is just skipping the charade that passwords are where the security happens.

With almost all current systems the place security really needs to happen is at the email provider. If you can hijack/intercept a users email or hack their account then it's game over with a password anyway, thanks to password resets being (almost) universally done over that channel.

There's an argument that this is no bad thing as security focused email providers could potentially provide very secure access as part of their core business (unlike a startup just trying to get going).

But there's still something bugging me about this implementation I can't put my finger on.

<comment><USER12> The only thing that's bothering me is that it is done through e-mail. I would prefer the token to arrive as a text message to my phone number. I feel like it is safer and faster. However, I understand that it is more expensive option, especially for services where you need to log in multiple times, compared to mobile apps where you log in only once.

<comment><USER13> SMS (in it's classical form) is highly spoofable as has been proven with TAN codes time-and-time again. It will work most of the time (sms has no guarantee of delivery as far as I know) and is somewhat secure but by no means good in any way.

This relies on email, which is highly secure, smtp is not spoof-able, server and mail origins are traceable and verifiable and there is no way to intercept the message on a malicious router/switch whatever. Ow wait ...

</comment></comment></comment><comment><USER14> I built (essentially) this a few weeks back, for an iOS app. Currently trying to get Apple's App Review team to agree it's a good idea.

Apple has UI in App Store submission that lets you provide App Review with a demo account username/password combo, but only that.

So to highlight another drawback: sometimes being able to share login credentials is a feature. Part of me thinks this ought not to be the case, and I hope I will be able to stick with password-less login.

<comment><USER15> Can't you just whitelist some token for them? If the sharing is the issue you're having with them anyway.

<comment><USER14> I'm looking at that. I don't know what email they will use to test, and I don't know if they'll look kindly at a special case for reviewers. Do you have any experience with that?

</comment></comment></comment><comment><USER16> Is it really necessary that the email link is clicked on the same device or to use a typeable token? Clicking the link on any device is enough to confirm to the server that the login attempt should be granted access. The server can then send and authentication token to the browser where the user is logging in.

The downsides I can think of in that case are an attacker attempting to log in at the same time, or -- more generally -- a user thoughtlessly clicking the link when an attacker is trying to log in.

The first problem can be addressed by displaying a second readable token on the login screen which the user should verify is present in the email before they click the link. That is how banks and other high security systems do it here in Norway now when you select authentication via mobile, except they use some sort of mobile communication tied to the sim card instead of email. You get a popup on your phone containing two random words from a dictionary. You confirm that the words match what the browser is currently displaying and then tap "OK".

The second problem can probably be reduced by short token timeouts and using appropriate language in the email to emphasize the implication of clicking the link uncritically.

</comment><comment><USER17> cons: If the customers email service goes down, then their access goes down. If your email service goes down, then the service goes down for everyone. If a major email provider is compromised, then a bunch of your accounts can be compromised. All public server-to-server email communication takes place over port 25, unsecurred clear text. That seems like a poor choice for anything security related in 2017.

If anything we should be removing insecure protocols like email, telephone and SMS from the authentication chain rather than relying on them even more heavily than we already do.

I hate to suggest it but authentication via something like WhatsApp might be more secure.

<comment><USER18> Server-to-server email is mostly STARTTLS (but without certificate validation) these days, I believe. Not great, but better than you think.

</comment></comment><comment><USER19> An interesting idea for a few reasons.

Users don't have to remember passwords, which is a strong benefit, but the user's security is now dependent on the security of their mail provider, or their own security practices in relation to the use of that mail provider, and in all likeliness their smart device.

With the ubiquity of smart devices, this works from a UX point of view and could be really streamlined, but I wonder how much the meme at the top of the article is actually betraying - this is the service provider not wanting to be responsible for your security in relation to their service.

I'm not suggesting that this is unreasonable per se, but the ultimate evolution of this model looks like it could (potentially dangerously) increase the value of a smaller surface area (the smart device) and put a fairly huge onus on the end user understanding and being responsible for their security.

And whilst that seems ostensibly ok, we already _know_ that the weakest link in security is the end user...so this could be putting all your eggs in one basket.

<comment><USER20> > but the user's security is now dependent on the security of their mail > provider

Let me put it this way. In many (but not all) cases I would much rather Google be responsible for my security rather than some random startup whose primary objective is to stay alive, not take security seriously.

<comment><USER21> It's funny you say that because I feel the same way as a developer. However, users of my site wanted password-based logins even though I support multiple social logins (Google, FB, Microsoft, etc.). Granted, I use PBKDF2 salting and hashing and I take security seriously, but it's interesting how average people sometimes don't trust social providers or think I'm storing their credentials to that provider.

</comment></comment></comment><comment><USER22> Password-less login is a bit of a weird naming. I'd call it one-time passwords. And then I'd maybe not use email, since this clutters the inbox. Instead something like Google Authenticator or SMS passwords would be a good solution, the latter maybe being a bit expensive for the service provider.

<comment><USER23> That would make having an SMS-capable phone nearby a hard requirement to simply login to some service. I am fine with offering additional authentication methods — if they are safe enough for that application — but dismissing passwords as a concept (unless you are scaling up to proper 2FA, e.g., Fido U2F) just means losing users for no good reason.

</comment></comment><comment><USER24> You can easily leak whether someone has an account on your website -- if I know their email address and input it, does it basically tell me? This limits your ability to reasonably error if the email address inputted is wrong.

Still, a lot of "forgot password" forms seem to be subject to this, too.

Also, you can only have one account per-email -- a disadvantage for some types of service, but admittedly probably a good thing for most.

</comment><comment><USER12> This is similar to what Whatsapp (and some other apps) are doing. The only difference is that they are using phone numbers.

</comment><comment> mike-cardwell Loosely related. Why doesn't my web browser speak IMAP? If I could just enter my IMAP details into my browser settings, then it could silently IDLE on my Inbox, and inform my currently open [http://example.com/](http://example.com/) tabs when it receives email from an @example.com address.

You'd need to stick it behind a "This website wishes to be notified about email you receive from it" prompt.

But then you'd be able to do all sorts of clever stuff, including streamlining email validation checks and password resets.

Everybody has email. You could create a "Login with Email" function really easily on your website, and it would work for even more users than the "Login with Facebook" option.

<comment><USER25> why should the browsers speak every protocol?

Why should everything be done through the browsers, instead of better specialized programs?

Why should protocols designed for one problem be abused to solve other problems?

Why not use client certs instead?

<comment> mike-cardwell "Why should the browsers speak every protocol?"

Why should browsers only speak HTTP? Who made that rule?

"Why should everything be done through the browsers, instead of better specialized programs?"

I never said "everything". "Better specialised programs"? What are you talking about? I'm talking about essentially being able to access email from a webpage. There is no "better specialised program" for doing that. I'm not talking about webmail. I'm talking about automated emails.

"Why should protocols designed for one problem be abused to solve other problems?"

What you call "abuse", I call "use".

"Why not use client certs instead?"

This has nothing to do with anything I've mentioned.

<comment><USER25> No better program to access email from anywhere than a browser. Have you heard about MUA-s?

Special mails should be used for authentication which would specially handled by the browser accessing your mailbox. This is abusing the mail protocols in my opinion.

Certificate based auth does have something to with this: an existing, partially supported solution for auth with no magic needed and no need to reinvent the wheel, with hacks and extra complications.

<comment> mike-cardwell "No better program to access email from anywhere than a browser. Have you heard about MUA-s?"

You understand the difference between accessing email and reading email? I'm talking about JavaScript accessing email, and acting on it. You're talking about a human being reading a message.

"Special mails should be used for authentication which would specially handled by the browser accessing your mailbox. This is abusing the mail protocols in my opinion."

We're already sending registration emails and password reset links. We currently have a system where the end user has to read an email and click a link in it. My suggestion would just allow us to skip the human part and let the JavaScript read it directly, _with_ a perfect fallback built in for people who don't have their browsers configured to have access to their mail.

"Certificate based auth does have something to with this: an existing, partially supported solution for auth with no magic needed and no need to reinvent the wheel, with hacks and extra complications."

Even with certificate based auth, you'd still end up having email involved with registration or password resets in some fashion.

<comment><USER25> You know, there is one thing I don't ever want to happen: to have JS running in my browser access to my emails and act upon that automatically.

This has way too many security implications which don't make it a reasonable idea:

1\. If sites can set up such action, then for that (I don't trust anybody's site to have any form of Access to my emails, except my mail providers per se),

2\. if the browsers supply these actions, then for that cause (it would be exploited, or if it would be perfectly secure then it would also be perfectly useless).

<comment> mike-cardwell What security implications are there for a tab with the example.com origin to be able to read emails that you receive from an example.com email address? If it's behind a user access prompt, and the API requires that you specify the sender and recipient to monitor for? E.g:

      navigator.notifyOnEmail({
        from: 'sender',
        to:   'recipientaddress',
      }, (email) => {
        /**
         * This callback is run whenever a new email
         * arrives from sender to recipientaddress.
         * Assuming the browser has access to the
         * recipientaddress account via IMAP, and
         * assuming the sender address matches the
         * browser origin and the user has given the
         * origin permission to do this.
         */
      });

<comment><USER26> > that you receive from an example.com email address?

How do you know that it really was from that email address?

<comment> mike-cardwell Why do you think that matters? The sending site knows if it sent an email. The only thing it doesn't know is if you received it.

For an account registration or password reset email, the sending site will typically send you an email with a link inside it containing a secret token. If the JavaScript reads that it received an email with one of those links in it, it will post that information back to the server so the server can complete the function it started (account registration or password reset). Obviously, at that point, it will know if the token it was passed was the one it sent.

[edit] Also, as this system is being implemented from scratch, it could easily be decided that emails which don't pass DMARC for example will simply be ignored. Although I argue that is not necessary.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> >Claim: With this setup, I can't login easily with my LastPass, 1Password, etc browser extension. >Rebuttal: This is a legitimate claim but it's equally plausible to use an email integrated browser extension.

You could do that, but since this isn't a very common login scheme, these might not exist/be popular yet. Also, some of us use password managers that aren't browser integrated, and that further reduces the chance of me having a decent workflow for logging in to the site.

</comment><comment><USER28> I'm glad to see this idea gaining traction. Passwords are a lazy solution that is often not needed. This type of login is ideal for websites and services that I might use less than 4 times a year.

I usually log into such services by doing a password reset every time I visit their service, and this technique at least removes the risk of password leaking.

</comment><comment><USER29> This is commonly referred to as OTP and I have implemented it on a few recent projects. It is very common in Asian countries.

</comment><comment><USER30> also [https://passwordless.net/](https://passwordless.net/)

</comment><comment><USER25> > Strawperson argument

Will this newspeak fury ever stop?

</comment><comment><USER31> For WordPress:

[https://wordpress.org/plugins/passwordless- login/](https://wordpress.org/plugins/passwordless-login/)

<comment><USER21> Just what Wordpress needs.

</comment></comment><comment><USER32> >Con: If database is compromised and passwords are reused across sites, then attackers might be able to access more sites

Never heard of hashing or TLS/SRP?

<comment><USER33> Those alone are not enough, a compromised database storing hashed passwords behind a service that uses TLS would still allow the attackers to try common passwords and hashing algorithms to see what passwords were used.

Password simplicity and reuse (especially across lots of people) is a major problem with password security in data breaches.

</comment></comment><comment><USER34> So, nothing new since Kerberos?</comment>


Interview with Evernote Founder Phil Libin - <AUTHOR> http://itsamonkey.com/podcasts/news-facebook-takes-search-social-with-graph-search-interview-with-evernote-founder-ceo-phil-libin

<comment><USER2> Really enjoyed the interview.

A small side note: <http://i.imgur.com/nUfqDsF.png> I was confused for a second--couldn't remember what link I had opened--and only accidentally noticed the scrollbar. (1366x768 resolution.)</comment>


Ask HN: What inspired you to become an entrepreneur? - <AUTHOR>

A very open question. I'd like to hear about the things that have inspired you to become an entrepreneur. Doesn't matter if it's a book, a person, an event, etc...<p>My story is boring (which is why I want to hear yours). Something changed when I witnessed the boom of online advertising in the early 2000's. I was around 13 at the time, and had been hosting several Counter-Strike servers for my friends (and myself). Around the same time, I had been [unsuccessfully] trying to make money online (surveys, a few ponzi schemes). Eventually I learned about SEO and Adsense...within a few weeks I had a website up about managing video game servers (received ~15,000 unique visitors/month at its peak). Walked away that summer with a little over $5,000 and I've had a different mindset ever since. <comment><USER2> I went to school for commercial photography and like most young photographers, if you can't land a good job in the industry you freelance.

The years I spent being a freelance photographer taught me a lot about running a business, but I ultimately fell in love with the freedom. Years later I read Tim Ferris' 4-Hour Work Week and knew I wanted more work/life balance than I was getting working for an agency.

</comment><comment><USER3> My last enployer was not very good and did some things that did not align with my moral, so I thought to myself "I can do better than him" and started a company with three other student friends to prove that I could do it better.

This was back in the days when coax cable & token ring was still a thing and IE was the only browser on windows...

Took a loong time, but now I know I am doing better :)</comment>


Geek Alarm at Campus Party Berlin - is this us?  - <AUTHOR> http://salon.io/SL/campus-party-berlin

<comment><USER2> It seems to me that this event wants to be something it isn't. I think they want to get all the "cool nerdy people" and got marketing/twitter people and gamers that thought it was a big LAN Party.

I heared about a guy who wanted to leave and the security kept his laptop, because they couldn't verify if it was his or not. nightmare!

If you want a real "hacker" event, participate the 29c3 (now in Hamburg) shortly after christmas.

<comment><USER3> Or Euskal Encounter (euskal.org) in Basque Country (Spain). Quite good for scene, hacking (very good security contests), programming but also good if you want to play games, dance or whatever.

</comment></comment><comment><USER4> A few creepy pictures of the female gender there. Do they want even less of those participants?

[http://www.schneier.com/blog/archives/2012/08/sexual_harassm...](http://www.schneier.com/blog/archives/2012/08/sexual_harassme.html)

<comment><USER5> That picture of the Facebook recruiter is also on the main page of <http://salon.io/> as the most representative (?!) image of the event.

<comment><USER6> I guess some clarification is needed here. The submitted page is a collection of photos by Stefan Landrock. Stefan Landrock runs salon.io. The submitter "lrock" would be Stefan Landrock (his e-mail address is lrock@...) unless someone is faking. While the account is old, this is the first submission and the first comments.

So I really do not get what this is about. The title sounds like some armchair hostility against ... whom? And people are reading some sexual harassment into the photos and blame the event instead of the photographer?

<comment><AUTHOR> You unlocked the sherlock badge!

</comment></comment></comment></comment><comment><USER7> This seems to be a masterpiece of "how not to organize a technical event"

<comment><USER8> Indeed. This is a commercial event with too much security - quite the opposite from the usual hacker events in Germany. You need to give lots of info on registration including a passport style photo, your laptop serial number (because equipment is required to be tagged) and apparently bags are searched on entry and exit. It's ridiculous. That's why the usual hacker crowd in Germany totally ignores this event.

<comment><USER9> How would you handle security at a 10,000 people event where laptops are likely to be left unattended ?

It seems given that scenario tagging laptops and checking them on entry/exit is probably the most effective solution.

<comment><USER8> These procedures trade my freedom and privacy for security. I always have someone keep an eye on my stuff, but I've also been at similar events (Chaos Communication Camp 2011) where keeping something unattended was not a problem at all.

Treating all you attendees like potential thieves is simply a bad premise for a hacker event.

<comment><USER9> According to the CCC FAQ Laptops have been stolen in the past

<comment><USER10> Yes. Of course. And there have been or will be stolen laptops at this event. The "security system" is easy to circumvent, if you do a little planning and want to steal something. The stickers are removable and re-attachable. You can register whatever, whenever you want. It is not done at the door. On my MacBook the serial number was taken from a screen, that I prepared.

But even the CCC had several years of congress with this kind of "security". So I am not mad at the organizers. We even had one congress where every participant had his/her photo taken. This actually had a major uproar and wasn't done ever again. I think maybe the organizers will learn and do things differently next time. At least I hope if they do this again in Berlin.

The most ridiculous things like not bringing lighters or no smoking outside the Hanger was removed from the Term & Conditions.

</comment></comment></comment></comment></comment></comment><comment><USER11> I'm getting a 502 bad gateway, has being on the front page crashed the site?

<comment><USER12> maybe, they're in beta. great service btw, I recommend checking it out when it's up again :)

<comment><USER11> Thanks for the recommendation, mind telling me what the site is all about?

EDIT: Can't reply to you so I +1'd you instead, thanks for a great answer :)

<comment><USER12> a new way to quickly build beautiful photo/artwork galleries. you drag and drop your pics, set how you want them organized (with some customizing of size, spacing, etc) and awesomeness happens. great for portfolios but not only, I used it as my travel pics gallery.

all powered by html/js and technically it's build as a single page app <http://blog.salon.io/2011/08/27/salonhazbackbone.html>

//edit: it's back, you can browse the galleries on the main page <http://salon.io/>

</comment></comment></comment></comment><comment><USER13> Looks exactly like a common recruitment event.

</comment><comment><USER14> i'm trying to find a ticket, does anyone have an extra one to sell/giveaway/rent/etc.? -> email@example.com thx

<comment><USER15> I don't think the tickets are transferable, as mentioned in another comment, they require you to upload a picture when buying/claiming the ticket...

<comment><USER2> that says enough about the organization. if there is a campus party 2013, i guess they'll require you to give them fingerprints, iris scans and your shoe size.

</comment></comment></comment><comment><USER16> Hope your geek alarms are going off for all the 502 bad gateway status codes your static servers are rendering...

</comment><comment><USER17> greetz lrock, hope you'll be able to handle the load! ;) maybe give varnish a try.</comment>


Why Get Satisfaction won't make your users satisifed - <AUTHOR> http://iphone.broadersheet.com/2009/10/get-satisfaction-on-your-iphone-app/

<comment><USER2> This is precisely why I haven't left feedback for a lot of sites using this service. When I go to leave feedback, I almost consider it a favor to the company (time is money, right?) but as soon as I hit that login/create an account form I bounce.

<comment><USER3> And I dream of more wiki like user feedback/support platform that _doesn't require_ signup.

<comment><USER4> UserVoice doesn't require signup to submit an idea by default (it's admin selectable).

</comment></comment></comment><comment><USER5> Hi all, A quick clarification: Get Satisfaction not only offers Single Sign- on, but we also support one-click login with all the popular login systems (Facebook, OpenID, Twitter, etc). No need to create a new account.

One more thing-- our roots are in community support, and a great many conversations are people posting questions that need answers or problems that need solutions. In order to notify them when there are responses, we need an email, and (by extension) some authentication for them to change their notification settings at a later date. With a super-lightweight account system we're able to service a range of customer support needs.

Still, we're always looking to improve our offering, so thanks for all the feedback!

<comment><USER6> What if you had an option to just put in an email to get responses to, and include any opt-out junk in the email itself? I think craigslist is a good example of how to do this. I agree with the top post: If I have to log in just to help a company out, I won't care enough to waste my time on it. If I have a real complaint, I'll send an email to the company or a real letter. I understand getsatisfaction is not craiglist, but there are some good ideas they are implementing.

</comment></comment><comment><USER7> Uservoice has Single Sign-On <http://uservoice.com/faq#sso> Unfortunately it's only available on the more expensive plans.

Animoto are using it here: <http://feedback.animoto.com/pages/9153-general>

<comment><USER8> fwiw we (uservoice) also allow anonymous feedback and have a 50% off coupon for any startup.

<comment><AUTHOR> 50% discount if a startup asks?

<comment><USER8> There's a coupon code in the sidebar here: <http://uservoice.com/for/startup>

<comment><AUTHOR> neat. thanks for doing that.

</comment></comment></comment></comment></comment><comment><USER9> When I implemented pretty much the first idea/feedback communities at salesforce.com (<http://ideas.salesforce.com>), past basic specs, my top ask was for single sign on. I completely agree that our users are doing us a favor by giving us feedback. It's our job to make that as painless and fruitful for them as possible. Also, we had some great people who made it a program that is very tightly integrated with the roadmap planning process. This was at least as important to our success as all the snazzy web 2.0 features we threw in. No point in asking for feedback if you don't make a commitment to deliver on it.

<comment><USER8> Too true. It's the commitment to the process from people that can actually effect change that's often times the hard part.

</comment></comment><comment><USER10> Our feedback widget from <http://featurelist.org> doesn't require any login and the email is optional. It's modeled after the same sort of side-widget you see on a lot of YC sites.

The idea is to get the user feedback as quickly as possible before they get tired and their good will is drained. We liked this so much we made a service for this that we use on all of our sites (and is free for you to use on your sites, too).

That feedback is private and can be promoted as either an upvote or a new public feature request by a member of your team.

For users to leave a public feature request on a project themselves, they do have to create an account. But that process is like Reddit in that you create it just with a name and a password without having to provide anything else (email is optional).

</comment><comment><USER11> Follow this feature request on Get Satisfaction at [http://getsatisfaction.com/getsatisfaction/topics/is_there_a...](http://getsatisfaction.com/getsatisfaction/topics/is_there_an_option_for_customers_to_ask_a_question_without_it_being_public_and_or_anonymously#reply_1467530).

</comment><comment><USER12> In my opinion those tabs on the side of the screen look really tacky too.

<comment><USER8> The best performing site we ever had (uservoice) was for StackOverflow and they just had a red text at the top of the page that said something to the effect of "Help us build the site" and linked to their uservoice forum.

We also have a lot of people connect widgets to custom anchors (super easy).</comment></comment>


Backblaze Hard Drive Stats Q1 2019 - <AUTHOR> https://www.backblaze.com/blog/backblaze-hard-drive-stats-q1-2019/ <comment><USER2> As someone who runs a tiny archiving operation (about 70 hard drives) I find these stats invaluable and am so grateful to you for publishing them! You make it a lot easier to navigate an expensive and intimidating world of hardware options.

<comment><USER3> Yev here -> Glad you enjoy them! Thanks for reading!

</comment></comment><comment><USER4> I've enjoyed the Backblaze hard drive failure rate posts for years, but never realized they publish the underlying data! [https://www.backblaze.com/b2/hard- drive-test-data.html](https://www.backblaze.com/b2/hard-drive-test-data.html) (scroll down)

It looks quite detailed--a daily snapshot of all of the SMART values for each individual hard drive.

<comment><USER5> I don't know why but every time I read one I'm never disappointed. I find the data fascinating. I wish more companies would give information like this but on memory, cpus etc also.

<comment><USER6> You know, I'll bet Backblaze goes through lots of memory, cpus, etc, too. Yev? :)

<comment><USER3> Hah yes, but likely not in the quantity that would make this interesting!

</comment></comment></comment></comment><comment><USER7> How have they got 2k boot drives for 100k data drives? Are these special motherboards with 50 (!) SATA connectors on them? Or is it many machines netbooting and share-mounting root from a handful of control nodes? I get that it's backup, so most of the data is at rest most of the time, but that still seems like a really high ratio of network ports to disk drives.

Either way, interesting that the boot drives are actual drives and not SD card pairs or something, like how vSANs are often set up.

<comment><USER8> Yep, the latest pods have 60 drives:

[https://www.backblaze.com/b2/storage- pod.html](https://www.backblaze.com/b2/storage-pod.html)

<comment><USER9> Using 16TB drives you will get 9.6 Petabyes of storage per Pod 6.0. It would fit you circa 21,276 blu-ray rips.

<comment><USER10> You mean Linux ISOs.

</comment></comment></comment></comment><comment><USER11> I'm really interested to see how those high capacity Helium-filled drives hold up over time. (i.e. I've been wondering how much leakage is going to be a problem)

<comment><USER3> Yev here -> that info should be in the SMART stats, so if you see a dip, checking there will give you a lot more context (though we'd likely call that out in our blog).

</comment></comment><comment><USER12> Does Backblaze have any SMR drives in use, or do you have plans to start using them? Would be really interesting to see if these exhibit a worse failure rate.

Anyway, thanks for sharing this data, I really like the openness.

<comment><USER3> Yev here -> No SMR drives in production at this point in time!

</comment></comment><comment><USER13> I thoroughly enjoy reading these stats every time they're released.

It's just a shame that their user interface is missing many features I want, otherwise I would use them.

</comment><comment><USER14> I'm just glad it works, I'm a Backblaze customer:)

<comment><USER3> Yev from Backblaze -> as an employee, I'm glad it works too :D

</comment></comment><comment><USER15> Still waiting for the Europe datacenter so I can start my backups :)

</comment><comment><USER16> my prediction: all four items in the list of predictions will happen.</comment>