You don't need reproducible builds - <AUTHOR> http://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducible-builds.html <comment><USER3> There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed.

First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if you don't compile the binaries yourself, you might not find out until later that a binary was compromised, but that's still better than never finding out. The reality is that most people don't want to spend time building all their packages from source...

More generally, reproducible builds make build artifacts a pure function of their inputs. There are countless reasons why this might be desirable.

\- If a binary is lost, it can be rebuilt _exactly_ as it was. You only need to ensure the source is preserved.

\- If a particular version of the code is tested, and the binary is not a pure function of the code, then you haven't really tested the binary. Bugs could still be introduced that were not caught during testing because your build is non-deterministic.

\- It provides a foundation for your entire OS image to be built deterministically.

\- If you use a build cache, intermediate artifacts can be cached more easily, and use less space. For example, changing the code from A -> B -> A will result in two distinct artifacts instead of three.

<comment><USER4> > \- If a particular version of the code is tested, and the binary is not a > pure function of the code, then you haven't really tested the binary. Bugs > could still be introduced that were not caught during testing because your > build is non-deterministic.

This is a weaker argument IMO because when building for test, generally, all optimizations are disabled, debug info is emitted, symbols are un-stripped, and so on. The unit under test is usually very different from the shipped artifact even at the module level. Not least because the test functions are compiled in.

<comment><USER5> If that's really what you are doing, then you are doing it horribly wrong.

<comment><USER4> You test prod builds?

<comment><USER6> As part of the release process, yes...absolutely.

Compared to basically every other part of release qualification (manual QA, canarying, etc.) re-testing on the prod build is so unbelievably cheap there's no reason to not.

<comment><USER4> I suppose we're referring to different kinds of testing. Manual QA, etc, on prod sure.

But if you're building client software artifacts, to unit test or integration test involves building different software in a different configuration, with different software and running it in a test harness. To facilitate unit testing or integration testing client software you:

\- Build with a lower optimization level (-O0 usually) so that the generated code bares even a passing resemblance to what you actually wrote and your debugger can follow along.

\- Generate debug info.

\- Avoid stripping symbols.

\- Enable logging.

\- Build and link your tests code into a library artifact.

\- Run it in a test harness.

That's not testing what you ship. It's testing something pretty close, obviously, but does not bear any semblance to a deterministic build.

<comment><USER6> No, I'm saying you re-run your automated unit tests on the release build because there's no reason not to.

If you have test failures in opt/stripped mode, they're more annoying to debug yes, but wouldn't you want to know?

Another way of putting this is that when you

> \- Build and link your tests code into a library artifact.

You build and link the same object files that will be built into the release binary artifact, deterministically.

> \- Enable logging.

I, uhh, usually do this in my released software too.

<comment><USER7> > I, uhh, usually do this in my released software too.

Do you have any idea how annoying it is to get logged garbage when starting something on the command line (looking at you IntelliJ)?

I once spent several weeks hunting through Hadoop stack traces for a null pointer exception that was being thrown in a log function. If the logging wasn't being done in production, I wouldn't have wasted my life and could have been doing useful things. Sadly, shutting down the cluster to patch it wasn't an option, so I had to work around it by calling something unrelated to ensure the variable wasn't null when it did log.

<comment><USER6> Yes, which is why I regularly (think quarterly or annually) check to make sure we have good log hygiene, and are logging at appropriate log levels and not logging useless information.

I have alerting set up to page me if the things I care about start logging more than the occasional item at ERROR, so I have to pay some attention or I get pestered.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> > _Q. If a user has chosen to trust a platform where all binaries must be > codesigned by the vendor, but doesn't trust the vendor, then reproducible > builds allow them to verify the vendor isn't malicious._

> _I think this is a fantasy threat model. If the user does discover the > vendor was malicious, what are they supposed to do?_

> _The malicious vendor can simply refuse to provide them with signed security > updates instead, so this threat model doesn't work._

For me, this is one of the primary benefits of reproducible builds and the author's dismissal of it as fantasy is unconvincing.

Vendors trade on trust. If a reputable application uses reproducible builds and discovers that a platform vendor is modifying their application on their platform, that information is damaging to that vendor's reputation. That's extremely useful leverage against potentially malicious vendors.

<comment><USER9> And vendor malice isn't the only reason why the software might be harmful. What if the vendor's toolchain was compromised without their knowledge? Reproducible builds provide a means for third parties to verify that it wasn't.

<comment><USER10> The holy grail of reproducible builds is achieving the same binary via different compilers. This was, at least when I started looking into reproducible builds, why I wanted to do it and why others wanted to do it. The other benefits are kind of side benefits.

<comment><USER11> This can't be correct. What would be the point of different compilers be then? There's no way that every compiler would produce the same exact insrtuctions for each respected input. There would be no point to using an optimizing compiler or one with better intrinsic support.

<comment><USER12> Perhaps you're comparing a multithreaded version with a single threaded version, or a single-host build vs distributed build.

When adding new features to a compiler, you might want to verify that the old and new versions have the same output given the same input. If your compilers produced non-deterministic output, this exercise would not be possible.

<comment><USER11> I took the statement "different compilers" to be completely different projects and codebases. Of course reproducable builds make sense in that situation. But why in the world would you ever expect gcc to 100% always match the output of llvm? That doesn't make sense.

</comment></comment></comment></comment></comment></comment><comment><USER13> So, we have source code for the signal app.

We can audit that source code, to ensure no key-leakage occurs.

Next, I install signal on my phone via the app store. How do I know the app I installed matches the source code that was audited? After all, google / Apple could decide / be forced to provide a modified binary.

Reproducible builds work for that.

Alternatively, consider debian. I ain't got time to compile every package I want from source (otherwise I'd run gentoo). Requires so much more dependency hell I'd rather avoid. With reproducible builds, I can check the source for any package, and so can every other curious person. This way, instead of everyone needing to set up their own build environment for every package, we can all depend that once in a while, someone checks whether a build actually comes from trusted source code.

Is it less secure than building myself? YES. Does it make deploying compromised code more likely to be detected than without reproducible builds? Also yes!

Heck, if we change from "depend that once in a while, someone checks whether a build actually comes from trusted source code." To a federated system of trusted checkers. It gives pretty nice guarantees, and makes depolying compromised code pretty damn scary.

Essentially. Whenever the person compiling / signing the binary is not the person writing the source code, reproducible builds are pretty dang nice.

<comment><USER5> > Next, I install signal on my phone via the app store. How do I know the app > I installed matches the source code that was audited? After all, google / > Apple could decide / be forced to provide a modified binary.

> Reproducible builds work for that.

You read the original post, right? He discusses this at length. Actually, right in the beginning.

In short, if you go through the dance of building the binary yourself to compare it to what's installed, then you could just use the binary that you just built, without ever looking at what the app store has.

<comment><USER14> If the app store distributes binaries to thousands of people, and only one of them rebuilds from source to check, those thousands of people gain a substantial (but not perfect) level of protection.

<comment><USER15> Yes, it would be "not community-minded" if you did a build, and it didn't match the app store, and you told _no one_.

</comment></comment></comment></comment><comment><USER16> A number of large companies are quietly moving towards reproducible build. Sorry if I cannot name the names.

As a side note, reproducible builds implemented in Debian were also useful to spot various other problem: small differences in build environment that would make debugging more difficult.

Sometimes the same application will have different performance depending on the build due to memory alignment, data ordering, cache friendliness.

Finally, the article is making some claims that are, frankly, incorrect:

> Q. It's easier to audit source code than binaries, and this will make it > harder for vendors to hide malicious code. > I don't think this is true, > because of "bugdoors". A bugdoor is simply an intentional security > vulnerability that the vendor can "exploit" when they want backdoor access.

Adding a backdoor and compiling a new "custom" binary might take 10 minutes and a lot of people in a company could do it and leave no traces.

Writing a "bugdoor", committing it and passing code reviews is very different. You might have to justify why you are touching a product / component / library that might be completely unrelated to your usual work.

Plus, you leave a very clear record of your action, giving up a lot of deniability.

> Q. It's easier to tamper with binaries than to write a bugdoor, so > reproducible builds do improve security. > I absolutely disagree, every > programmer knows how to write a bug or short circuit some logic. Hiding > malicious activity in a binary, with a multi billion dollar malware industry > determined to find it is more difficult.

This implies that the malware industry is somehow unable to detect a "bugdoor" or unexpected behaviors a runtime but able to detect a change to the binary...

> In addition, once you've produced and signed the malicious backdoor, it is > not repudiable - you can't deny you wrote and provided it.

Most organization track source code changes in a VCS but don't require employees to sign binaries with keys bound to each individual. If anything, this makes a point in favor of repro builds.

<comment><USER17> > A number of large companies are quietly moving towards reproducible build. > Sorry if I cannot name the names.

Thanks, user "ex_amazon_sde"!

<comment><USER16> I wrote "a number" and I was not referring to Amazon :)

</comment></comment></comment><comment><USER18> There's another reason I think reproducible builds could all a lot of value: app stores. Right now, if I install from a normal app store (Apple, Google, Microsoft), there's no real benefit to using open source apps. Even if I trust the app store, I have no way to confirm that the app binary matches the purported source.

App stores could improve the situation by building apps themselves, but I think that would put them in an position they don't like. App stores don't currently build their apps.

With reproducible builds, app stores could do better. An app store could list the hash of the build artifacts along with the purported name and developer, allowing various degrees of assurance that an app is actually a build of the source it supposedly comes from. Without reproducible builds, the app store would have to build the app itself and use its build instead in the submitted build, which seems undesirable.

Tavis's argument about bugdoors still applies, but IMO it's largely irrelevant to the major app threat model. Many useful apps don't have input and output that is susceptible to corrupt data. A lot shouldn't access the network at all. The common threat is that they include fifteen tracker SDKs, all of which _are malicious by design_. Including the entire Facebook SDK is going to be tricky as a bugdoor.

<comment><USER19> > App stores don't currently build their apps.

On iOS (not sure about macOS apps), when you submit an app, it is submitted as "bitcode" (note, this is not "bytecode" \- it's bitcode, not a typo). This allows Apple to build your app as needed from your bitcode (think of the bitcode as LLVM IR).

This is done for a couple of reasons: (a) they can take advantage of improvements in their backend compiler (IR->executable) that happens after you submit your app, (b) they can build your app on platforms that didn't exist when you submitted your app

The net result is that the App Store plays an important part in the build process, which could legitimately generate different binaries (even for the same device, see (a) above) for the same app you submit.

<comment><USER20> They could also wrap your app in code that does things you didn't intend, like telemetry/metrics, interception of certain functions, etc. (Not that they couldn't do that anyway)

</comment></comment></comment><comment><USER21> I don't know about the 'formal' description of reproducible builds used in the article from a security perspective, but I do know that having the exact same output locally as is being built by a deployment process makes debugging a lot more straightforward because it removes the subtle and hard-to-discover problem of having slightly different library versions in your application making things perform differently.

<comment><USER22> Right, and I like the ability to re-build a release from 6 months ago and get something that reproduces the behaviour of the previous build - i'm not concerned if the binary is identical, more that it is functionally identical. A typical way of breaking this would be for build scripts to move forward but not be made backward compatible, or easy for the previous version to be used for an old build (for example, a newer compiler getting used rather than the one originally used).

I've worked on enough stuff where releases get held up for various reasons (and so production software can be 6 months behind head) and there's a desire for a fix to the released version and hence changes made to a branch as well as head to apply the fix. This sort of thing is made much easier if you don't have to spend time trying to work out how to get the branch to still build!

</comment></comment><comment><USER23> The arguments "don't follow." Reproducible builds were indeed more than once used to verify that the published binary does correspond to the published source.

Without having them, that kind of verification is much harder, depending on the build setup used, it can be even too hard to be achieved at all.

So we do have clear advantages of having the build infrastructure which results in reproducible builds, and I don't see anything that can substitute that.

The argument "if you build yourself from the sources, your build is then trusted" is not reflecting the reality. Most of the users are never going to build from the sources. Having reproducible builds, only a few people have to build from the sources to verify the binaries for the vast majority. Not to mention that without reproducibility, you can't even know if your own build environment is misconfigured.

</comment><comment><USER24> Here's a hypothetical but a realistic scenario that not having reproducible builds is a major issue:

1\. I create an app for a client.

2\. Client installs the app on their 10,000 enterprise mobile devices and trains the users.

3\. Month passes. I've changed everything in the app.

4\. Major security or outage event happens. I need to change a line in the app and those 10,000 devices need to be updated ASAP.

5\. If I can't checkout the old version, change the line and ship it without wondering "what else will change in this build" \- then both me and my client are going to have a bad time.

It will take two weeks for a full qa/audit of the app and there's no time for that.

<comment><USER25> You are making the case for source control and having no external dependencies like npm, but you don't need reproducible builds for that.

<comment><USER22> I've a feeling there's multiple definitions of build reproducibility going on here. I'm guessing you mean that it's not important to be have something byte for byte identical, but more to ensure that exactly the same build steps were run with the same source code?

For most of us, that's what build reproducibility means, but I guess for a subset of users it means producing an identical binary.

<comment><USER26> > but I guess for a subset of users it means producing an identical binary.

Whenever I hear people talk about the problems of creating reproducible builds, I often hear stuff about timestamps or other metadata inserted by the compiler that would "break" the reproducibility (under the stricter definition).

Having your own source code versioned and dependencies version-pinned (and pretty high confidence that the dependency package foobar-1.12 stays the same over time) seem just like old fashioned "good practice".

The looser definition would imply that all versioned software without external dependencies (or the source of the dependencies manually included in the repository) is reproducible?

<comment><USER27> How many people pin the exact version of a system library they are using? Or of a binary used in the build process.

Also, how many people run the build in a sandbox to avoid "interference" from the environment?

Yes, this is all good practice, but I think very few people do it, because it's not easy.

<comment><USER26> Yeah, true. I was thinking of doing release builds in containers via the CI/CD pipeline, keeps the environment pretty static, but not completely static of course.

But further: All of these things would still not be enough for the strictest definition (exact same binary), at least with normal compiler defaults afaik?

<comment> yjftsjthsd-h > All of these things would still not be enough for the strictest definition > (exact same binary), at least with normal compiler defaults afaik?

Right, because of things like timestamps getting into the binary.

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> Hi Travis,

If you are reading this, I'm one of the members of the TUF [1] and in-toto [2] team, where we try to solve exactly this kind of problems. While I agree with you that reproducible builds sound a lot simpler than they actually are to achieve (and leaving aside all the practical complexities you mentioned in the blog post), I think they provide value for a certain use case seemingly not mentioned in the blog post.

It is the case where the vendor is a traditional Linux distro, and we have independent reproducible builders to ensure that a compromise of their CI/CD infrastructure is not enough to cause malware to be installed. It is true that the builders can still go off and reproducibly build malicious code, but this can be mitigated by requiring a high enough threshold of (presumably independent) developers to sign off the code. The problem of malicious source code is infeasible if not impossible to solve cryptographically, but we can make sure that CI/CD increasingly sitting on the cloud are not blindly trusted.

Could not post on your blog. Let me know what you think. Thanks!

[1] [https://theupdateframework.io/](https://theupdateframework.io/) [2] [https://in-toto.io/](https://in-toto.io/)

<comment><USER29> I think it's "Tavis" (no "r")

<comment><USER28> my bad, but still, no reply as yet...

</comment></comment></comment><comment><USER30> The premise of the article is ignoring difference between "trust" and "trust but verify".

And then there's a QA which answers criticism with "I absolutely disagree", "I think this is true, but".

> We know that attackers really do want to compromise build infrastructure, > but more often they want to steal proprietary source code, which must pass > through build servers.

This has shifted the goalposts so much they're on a different field now.

<comment><USER31> Yes, exactly. And crucially you don't need to verify yourself to get the benefits of verification. There is value in crowdsourced verification (i.e. I always have to choose a trusted vendor but it is safer when I know others might try building themselves and raise a fuss if there is a mismatch between their build and my vendor's build).

</comment></comment><comment><USER32> I think OP is coming from a different perspective than I (corporate bespoke solution builder) do. When I say "reproducible build" I mean a build that is the same on any machine (i.e. no special magic necessary to build a "official" version of the code). Too often in corporate environments, getting a local build or setting up a new build pipeline involves arcane black magic and/or copy/pasting weird libraries that can't be pulled from any sort of "official" repository. curl/bash libraries that "automatically change versions" based on when upstream decides to change them can wreak havok when setting up a new build environment. My $0.02, it's not (in the corporate world) so much about validating binaries, but more about "how many steps beyond check out the code" exist and how easily can I validate my binary uses the same versions of libraries/dependencies as the one that a local developer tested?

<comment><USER33> For this reason I've been dockerizing my builds for almost five years. I was late to the Docker party, but when I saw the benefits it brings to build pipelines, I was sold.

It's true that a dockerized build isn't any simpler than its non-dockerized ancestor, but at least there's a Dockerfile that lays bare all the black magic and special sauce which goes into each build. And it can be version controlled to watch for drift over time.

This stuff is useful in a corporate setting, but the other fetishization of reproducible builds is just a distraction that can stay where it belongs: open source mailing lists.

<comment><USER34> While your Dockerfile helps you know how a project was built at a specific point in time, it's not going to work forever. Even if the file doesn't change over time, the build it produces will. It's mainly because of installing packages using something like "apt-get install $package". It also can change if the files you're adding with ADD or COPY change.

<comment><USER33> You don't _have_ to download the internet upon each build.

First, in a corporate environment it's common to run builds backed by artifact servers that'll cache just about anything.

Second, it's easy to place files in a Docker build context (that's just a $25 dollar way of saying "next to the Dockerfile") that would have been downloaded from the internet, but are stored locally instead. This is easier said than done for some formats. Source tarballs? Easy. Anything Java or Debian that requires a pesky server which works a certain way? You're going to have to use a caching artifact server.

</comment></comment></comment></comment><comment><USER35> These arguments against reproducible builds are very provincial, temporally.

Which is to say, they assume a user _now_ downloading source _now_ to compile and use _now_.

One of the things I like about reproducibility is that someday, in the future, when the project is closed and the website is down and the author is dead ... we can take the source code and compile it and compare it to our own notes (or to the wayback machine, or whatever) of the checksums, etc., of the binaries and gain some confidence _that we have what we think we have_.

</comment><comment><USER36> I'm missing some context. I'm assuming the author is referring to binary distributions of open-source software? Otherwise, "reproducible builds" means something slightly different in a commercial software development environment. (Think of someone building an e-commerce site where the software is proprietary.)

Thus:

> You don't need reproducible builds

No, not for open source. If it's open source, it's only valuable and useful to have the source code if I can build it. Otherwise, if I can't build it, to me it's no different than closed source.

> You don't need reproducible builds

In a commercial development environment I need to build the code I work on. What about when a bug exists due to problems in the build environment? If I can't reproduce the build environment, I can't fix the bug.

</comment><comment><USER37> I can think of one argument against reproducible builds that really make sense:

You have some legacy system incapable of reproducible builds, and the social effort to convince people not to care is less than the technical effort to fix it.

</comment><comment><USER38> I think the author hasn't accurately described the workflow where reproducible builds are used.

Here's my attempt.

There are three entities:

1\. The vendor, who creates and _distributes_ a product, which may include software, to the end user

2\. The end user, who receives the product from the vendor, operates the product, and trusts one or more verifiers to correctly certify the product according to some standard that the user desires

3\. Verifiers, who receive proprietary access to the vendor's product (e.g. source code) and check that the product meets a set of standards and assert that fact to the users

Note that verifiers are NOT in the job of distributing products to users. That's a hard job and it seems understandable to me if verifiers don't want that job.

Reproducible builds help link a specific version of source code that a verifier certified to a specific product being operated by a user. Without it, the user trusts the vendor much more than with it.

Yes it adds brittleness and delay (see FIPS 140 certification). These are use case specific trade offs that only users can judge.

In the case where some facts about the source code can be formally verified, reproducible builds support that trust relationship much better. I might go so far as to say that reproducible builds are essential for trusting formal verification.

You can also imagine a software supply chain that includes more steps than a simple vendor -> user relationship. Much of the proprietary software used today include libraries from third party vendors. There are integrators that add their own special sauce. The supply chain looks more like: vendor -> vendor -> ... -> vendor -> end user.

Imagine each vendor has their own set of verifiers responsible for certifying that vendor's output.

<comment><USER39> but this just shifts the burden of who to trust to the verifiers. It didn't make the software from the vendor _any more_ trustworthy.

<comment><USER38> > this just shifts the burden of who to trust to the verifiers

Agreed. A colleague once said that trust is like a balloon; if you reduce trust in one area, you tend to expand trust in another area.

I think the typical response to your statement from a user is that it's easier to trust a set of verifiers than it is to trust a vendor. The act of a verifier blessing an artifact makes that artifact more trustworthy.

Personally I'm skeptical of these claims, but that's the underlying assumption of the certification process

<comment><USER40> Presumably there is benefit in reducing trust in a party with mixed or unknown incentives to increase trust in a party whose incentives align with your own. For a critical piece of software I could imagine a schema where a user pays one or more independent verifiers to validate the software. That would allow the user to control the incentives of the entities telling them the software is safe.

</comment></comment></comment></comment><comment><USER41> > What isn't clear is what _benefit_ the reproducibility provides.

The ability to cache build artefacts is a pretty huge benefit for my work.

</comment><comment><USER42> The post started out OK, but then I lost the plot

> Q. It's easier to tamper with binaries than to write a bugdoor, so > reproducible builds do improve security. > > I absolutely disagree, every > programmer knows how to write a bug or short circuit some logic. Hiding > malicious activity in a binary, with a multi billion dollar malware industry > determined to find it is more difficult. In addition, once you've produced > and signed the malicious backdoor, it is not repudiable - you can't deny you > wrote and provided it. > > With bugdoors, you don't need to deny it - <USER2> > just claim it was an error, and you're automatically forgiven.

If the binary vendor has the source code, _every source exploit is also a binary exploit_. If you can make a semi-"bugdoor" that's plausibly deniable, and then augment it with a binary tamper that's deniable as an artifact of non-deterministic compilation, is that not the ultimate coup de grâce?

</comment><comment><USER43> For me security is not the only thing that make reproducible builds interesting. I'm often interested to link a binary to its source in retrospect. This is at a time when the vendor might long be gone. It helps a lot to be reasonably sure that the source you analyze is the one that was used to build the binary and you don't waste time studying the wrong source.

The counterargument is, of course, that if you are serious you should look at the binary anyway and never trust the source, and I can't argue with that, except - for better or worse - that this is not the world I live in. For me an as short as possible time to answer a question about a software with as much confidence as possible is key. I'm alway grateful when I can reproduce the build with reasonable effort and then look at the source instead of the binary. Regardless how much I love to tinker with binaries, looking at the source is usually just faster.

</comment><comment><USER44> It looks like almost everyone here thinks this is wrong and poorly argued (as do I). A meta question to ponder: why did this get upvoted to the front page? Is it that upvoters tend to not read the articles whereas commenters do? Do people upvote stuff they think is wrong for the purpose of discussion?

<comment><USER45> > A meta question to ponder: why did this get upvoted to the front page?

The author is a sort of expert in the field, if he's calling out reproducible builds as security theatre, it's worth discussing

</comment></comment><comment><USER46> Ugh...

If building the same source produces different binaries, then I'd like to know (a) what is causing the difference and (b) what other differences does it cause?

Being able to produce a consistent result is simply a sign of professionalism.

<comment><USER47> How about using a different toolchain? (eg: gcc vs clang). Or even different versions of a toolchain? Or a dependency that has to be downloaded? Being able to build consistently requires way more effort than just following professional practices. One method I know is to pin everything that goes into a build - source, dependencies, toolchains, configurations and environment.

Results of non-consistent build can be as simple as a difference in performance. But it could also be a malware injected through the compiler.

<comment><USER46> Yes, yes and yes. The toolchain and the dependencies should be pinned.

Otherwise sooner or later you'll hit the customer's issue that you won't be able to reproduce - until you realize it's some subtle bug in the specific version of your compiler.

</comment></comment></comment><comment><USER48> I dont think that reproducible builds are perfect or solve every problem. I still think they are worthwhile though because they allow for a better audit trail, and every step that is auditable makes it easier to pinpoint at what step something bad happened.

Sure users arent likely to verify them. I still think there is value in after the fact being able to determine - clearly this binary came from this source code artifact vs clearly this binary was substituted as it doesnt match the source code. Its not perfect but it helps reduce the places where an attack can take place with nobody noticing.

</comment><comment><USER49> You know that principle that mathematicians invoke when someone "proves" P=NP? i.e. do they mention any of the classic problems in the space? Well, if you can't find the word "Debian" in an article on reproducible builds you can be reasonably guaranteed it's missed something.

</comment><comment><USER50> This post misses so much.

"What isn't clear is what benefit the reproducibility provides. The only way to verify that the untrusted binary is bit-for-bit identical to the binary that would be produced by building the source code, is to produce your own trusted binary first and then compare it. At that point you already have a trusted binary you can use, so what value did reproducible builds provide?"

Being able to reproduce a build not only validates the source but the entire process of creating the executed artifact. To properly capture this ability and value the CI/CD pipeline should also be reproducible in an infrastructure- as-code manner. Together with the programs' source and short documentation (as it should be coded) on how to put these parts together it means the operation of the company can be recreated in another geography/datacenter and continue to work while team members rotate out/in.

Contrast the situation with inheriting a codebase that only has possibly matching source code and a production environment that everyone is afraid to touch at the other extreme.

</comment><comment><USER51> This seems like handwaving and arguing against something good because some people don't know how to do things.

"Companies can have security issues. Servers can be compromised. So why try?"

Trying to assert that a demonstrable fact is opinion because the opinionmaker doesn't understand the fact isn't valid.

</comment><comment><USER52> I don't know anyone who would agree with this article, at least publicly. I want my 5 minutes back.

</comment><comment><USER53> Extreme build reproducibility requirement: had a customer in telecom. Their customers (carriers) required downtime no more than 5 (or 10?) minutes per decade — 7 nines I believe.

When they reported a bug they wanted the fix and then they differed the binary to be sure that every code change was related to the patch itself and nothing else. No additional fixes or upgrades. They were willing to pay through the nose to stay on a very old version of the code.

The code was in C (this was mid 90s) — can't imagine how much harder it might have been with extensive templating and the like.

</comment><comment><USER54> I think he's right about all the security arguments. It is definitely nice to have properly reproducible builds from a build system point of view though. Things like ccache would work a lot more reliably.

<comment><USER55> Also just increased confidence that the build is working properly.

I think there's added security for the first party builder in their own process: they can better audit the process from source code to deployment.

</comment></comment><comment><USER56> "More often, attackers want signing keys so they can sign their own binaries"

Isn't the idea that you don't have trust signing keys anymore because you rely on consensus? An attacker would probably have a much harder time compromising 10 vendors instead of one.

You are right, about complexity and issues, and you certainly don't "need" reproducible builds, depending on what you are after but it can be beneficial.

Also, you're arguments often seem to come out of thin air: "reproducible builds are not for users" Why? Maybe not for the average user (yet).

</comment><comment><USER57> My understanding of reproducible builds seems to be different. I always thought of it as a way of ensuring people couldn't deploy edited code from their workstation.

You would ask trusted system A build the code at a particular code-reviewed snapshot. It fetches the code itself, builds, and codesigns. Then you hit deploy on system B, which is the only system with credentials to modify prod. That system looks for A's signature. There's no vendor involved, so maybe I'm missing a better understood picture of what a reproducible build means.

</comment><comment><USER58> Build reproducibility doesn't solve the problem of "how do I know the computer I don't control is actually running the program I think it is?"

The only solutions are related to fully homomorphic encryption, which is a way of running a program on a computer you don't control where the operator of that computer cannot learn information about the work it is performing. Unfortunately, pure software approaches to FHE haven't been proven out.

It is possible to get the benefits of FHE by utilizing a software enclave, but then you have a different trust narrative that involves hardware (and attestation services). The point of remote attestation is that you can verify that a computer you don't control is running a specific binary (verified by the hash and a signing key) at a specific moment in time. The problem is that the chain of trust for the signing key traces back to the manufacturer of the enclave.

The holy grail would be some way of decentralizing the trust of the enclave OR finding a way to do purely software based FHE that was fast. I'm not holding my breath for the latter, but the former might be possible in the next decade.

In short, if you have a reproducible build but you don't have a way of verifying that binary is actually running on a remote server you don't control, the reproducibility of the build is a moot point. I sorta think the only systems where build reproducibility matters today are ones that use enclaves (but I'm willing to be disabused of this notion if people feel otherwise).

</comment><comment><USER59> Here are some answers:

[https://wiki.debian.org/ReproducibleBuilds/About](https://wiki.debian.org/ReproducibleBuilds/About)

</comment><comment><USER60> With reproducible build anyone can verify the build and everyone benefits from it. Without reproducible, no one can verify the build, never.

</comment><comment><USER61> For us, the biggest benefit of reproducible builds is debuggability. One year later, if we get a bug report from a customer, we can fully recreate the issue in house, patch it, and provide a new build with confidence that we fixed the problem.

Without this, in a huge interconnected system you go insane trying to control all the variables needed to figure out what exactly went wrong.

</comment><comment><USER62> Reproducible builds, combined with digital signatures and an append-only cryptographic ledger, solve a lot of these trust issues.

[https://paragonie.com/blog/2016/10/guide-automatic- security-...](https://paragonie.com/blog/2016/10/guide-automatic-security- updates-for-php-developers)

</comment><comment><USER63> > With bugdoors, you don't need to deny it - you just claim it was an error, > and you're automatically forgiven.

Interesting off topic point about the lack of accountability in the profession. Even as a sysadmin, one accidental iptables flag might let an intruder gain access. What will happen to me? Angry boss maybe.

</comment><comment><USER64> Too many people in this thread are mixing build systems vs security.

The author is talking about Reproducible builds about security and only security[0].

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

</comment><comment><USER65> Interested in reproducibility for caching/performance/debug/rollback reasons, not security. Thanks, Tavis, for clarifying that security gains are not useful. I don't usually consider them but when I have to, I'll look up this article.

</comment><comment><USER66> I would already be happy with working builds

If you use a non-mainstream compiler it is a horrible mess. Almost every other time I build my program, the compiler crashes and I have to make a clean build.

Recently they have fixed the issue, I updated the compiler, and now it still does not compile. Random type checking error. After a clean build, the type is accepted and it compiles. I tried to make a mwe, and instead of a type checking error, the the compiler crashes at that line.

At least it always compiles with a clean build. But the resulting program does not start (not accepted load segments). I have not figured that one out, so I uninstalled the update and keep using the crashing compiler version.

</comment><comment><USER67> Reproducable builds keep honest vendors honest. If I introduce reproducable builds, I make it likelier to get caught if I tamper with my own binaries. Likewise if I provide checksums for my downloads.

There are a lot of popular freeware and open source projects from small teams or individuals. You can't tell me that no one is at least a _little_ bit tempted to slip in a trojan occasionally.

</comment><comment><USER68> Forgive me if someone has already mentioned this, but if I have multiple vendors, why can't I compare the hashes of all of them before I ask for the binary? Then any one vendor is being held to account by the others before I install. No source is required, just the hashes of the source and the hashes of the resultant binary.

</comment><comment><USER69> Yes you do. How else can you trust an open source bitcoin client in the play store is the same version published on github?

<comment><USER70> The whole point of the article is that in order to check if the play store version is the same, you have to download the github version and build it from source. At that point, you might as well throw away the play store binary and use the one you just built.

<comment><USER71> Yes, but it takes just one person to download github source and build it to verify that a binary available in the play store is safe so that the other 1,999,999,999 Android users don't have to.

</comment></comment></comment><comment><USER72> If you're looking for an actual spicy take, you could say that reproducible builds are impossible once the durability of hardware/state of the universe is accounted for, but that the concept provides yet another black hole of cash and effort with which devsec can build a cottage industry around.

<comment><USER73> There is a trusted hardware industry emerging, so your story has plausibility

</comment></comment><comment><USER74> Define reproducible. I always archive dependencies so I can rebuild, even if that build has some new timestamps in it. Having a rando Github repo go down when you rebuild is not a failure mode I want.

</comment><comment><USER75> Given the choice between reproducible and the scattered disasters I've seen, reproducible seems better.

But I would be content with "pipelined", and have the readily automated part handle itself.

</comment><comment><USER76> Well, after spending so much time watching kilometers of rolling text on my screen while `emerge -uavDN @world` compiles __everything __, I agree I don't need reproducible builds

</comment><comment><USER77> Reproducible builds allow people to independently verify that a build came from the source code that the binary vendor claims it did, rather than some compromised source code.

</comment><comment><USER78> i think mostly we want to be as reproducible as possible is because a non reproducible build means there might be new bugs in it that werent there previously (when using the same source). for example a dependency might have been updated and might now be incompatible. it happens. its not malicious, but its annoying. this usually gives a lot of 'works on my machine' discussion, which is a rather frustrating and unhelpful situation.

</comment><comment><USER79> tavis assumes there's an complete organization which is either good or bad. but what about people with in the organization with restricted or accountable access to sources or binaries?

i think reproducible builds are about malicious parties in an bigger organization.

</comment><comment><USER80> Reproducible builds make it a lot easier for compiler/build system debugging.

</comment><comment><USER81> Not worth reading

</comment><comment><USER82> Reproducible builds are primarily useful at organizations with strong auditing requirements. The build system is the root of trust and it's possible to achieve a high degree of trust inside an organization.

I think what the author misses is that having multiple vendors or distributions providing signed deterministic/reproducible builds reduces the total cost of maintaining individual trusted build environments.

For example, the author claims that the most straightforward way of producing a trusted build is to do the build from source oneself. That is true, but ignores the cost of millions of individuals spinning CPU cycles to build their own local packages, which has already been deemed too high by most users.

If N independent entities build and sign reproducible packages for a distribution then the probability of incorrect binaries being produced is P(individual_problem)^N for as many N as local package managers want to check, or trust an aggregator to fetch and compare signatures from all N producers. N can be far smaller than the number of individual uses of the packages while still being more trusted than a single vendor maintaining their own highly- trusted build system. If large organizations participate in this multi-entity process they can only increase their own certainty that they've produced accurate builds from source for packages built publicly at least.

Deterministic builds also solve the compiler back door problem (ala "Reflections on Trusting Trust"). Compiling each repeatible/deterministic compiler (e.g. GCC, llvm, TCC, MSVC) with every other compiler and verifying that all deterministic builds are identical from any compilation path, e.g. that tcc(gcc(MSVC(llvm(tcc)))) produces identical output to MSVC(gcc(tcc(llvm(tcc)))). The process can be extended to verifying these paths under multiple OS's and hardware architectures. This establishes a practical root of trust; a well-known compiler binary trusted to translate source code into binaries without binary backdoors. [https://news.ycombinator.com/item?id=10181339](https://news.ycombinator.com/item?id=10181339) for previous discussion.

Finally, deterministic builds allow verifiable signatures of the form "This container OS with signature A running a software package with signature B with input having signature C produces output with signature D" for arbitrary choices of deterministic source code. This allows for verifiable computing in general; the ability to trust that the output of running compiled source on a particular input (including other source code) actually produces a particular output. This reduces the cost of establishing a trusted system from the high cost of building everything from source to the cost of building the root of trust from source and trusting the plurality of signatures establishing that building the rest of the system from this trusted root results in the same publicly available binaries. The process can be extended all the way to formal verification of the root of trust and any other desired components.

</comment><comment><USER83> interesting choice of domain name, any background?

</comment><comment><USER84> Has someone taken over Tavis's blog? Two posts in a row now that seem like he either just doesn't understand some concepts, or is intentionally disseminating nonsense that is pushing people in the wrong direction on things that really do bring about benefits related to security.</comment>


What research on coronavirus structure can tell us about how to kill it - <AUTHOR> https://www.washingtonpost.com/graphics/2020/health/coronavirus-sars-cov-2-structure/ <comment><USER2> Slightly older (I don't think it mentions the exterior sugars) but more detailed and comprehensive Economist article about the coronavirus structure and how it motivates research into different solutions (e.g., why do we hope remdesivir will help?): [https://www.economist.com/briefing/2020/03/12/understanding-...](https://www.economist.com/briefing/2020/03/12/understanding- sars-cov-2-and-the-drugs-that-might-lessen-its-power)

Was also previously discussed here [https://news.ycombinator.com/item?id=22572311](https://news.ycombinator.com/item?id=22572311)</comment>


Travis Kalanick paid $200,000 to the driver he insulted in a viral video - <AUTHOR> https://qz.com/1182896/ubers-travis-kalanick-paid-200000-to-fawzi-kamel-the-driver-he-insulted-in-a-viral-video/ <comment><USER2> A spokesperson for Kalanick told Bloomberg the meeting "ended on a positive note."

especially for the driver...</comment>


RetroBSD - 2.11BSD running in 128k RAM / 512k Flash - <AUTHOR> http://code.google.com/p/retrobsd/

<comment><USER2> Those specs are generous compared to the hardware on/for which 2BSD was developed.

I have used Mini Unix on a PDP-11/45 with 32 Kbytes (16 Kwords) of core memory and dual 2.4 Mbyte hard drives.

I once took a class, 6.031 at MIT, where we did our assignments on a PDP-11/45 running Unix on 256 Kbytes (128 Kwords) of RAM and three 2.4 Mbyte hard drives. That was a timesharing system with 16 simultaneous users.

The 11/45 was 1979, I think. The 11/40 was a year or two later.

</comment><comment><USER3> I now have a massively irrational desire to acquire one of these boards. I already own an arduino I barely touch, but the idea of having a unix at the center of a hack is very appealing.

</comment><comment><USER4> This is from the TODO list: "Port any visual text editor."

That means forget about running Emacs on this, or vim, or even plain vi. Perhaps the only available editor is "the standard editor."

<http://www.gnu.org/fun/jokes/ed.msg.html></comment>


Show HN: Trin Trin: Text That Rings - <AUTHOR> https://play.google.com/store/apps/details?id=com.trintrin.app&hl=en <comment><AUTHOR> Trin Trin is a social messenger which let's you text your friends in most alerting way. Tap on a contact, type and TrinTrin - Your friend receives a flashing text with ringtone and big typography till he/she responds with a simple tap on response templates.

I'd love to hear your feedback, currently android version is out and iOS is few weeks away. Here is our website: [http://www.trintrin.co](http://www.trintrin.co)</comment>


Ask HN: Would you pay for daily motivation? Personal trainers for goals? - <AUTHOR>

People on this site always talk about having people that you don't want to let down. I'm thinking a daily call, email or Skype for a few minutes with someone with the aim of them making sure you work towards your goals!
Kind of like personal trainers, except for your goals.
I got rather psyched while thinking about this and typing this post out, so I made a mailchimp list for those interested http://eepurl.com/dPRk-/ <comment><USER2> Have you considered doing a poll instead of a discussion question? You might get more lurker participation.</comment>


Show HN: My way of searching Youtube - <AUTHOR> http://christopherwoodall.com/youtube/

<comment><USER2> With the verbiage about dragging videos and a vast expanse of white, I spent a moment wondering whether something had failed to render before I thought to try typing something into Search.

Also: "embed", and don't be afraid to use capitalization.

All that having been said, the densepack display of video thumbs is nice.

<comment><AUTHOR> You are right. I have a long way to go.

</comment></comment><comment><USER3> I liked the overall idea. Give the search box a prominent position.</comment>


Wake Up, Geek Culture. Time to Die - <AUTHOR> http://www.wired.com/magazine/2010/12/ff_angrynerd_geekculture/all/1

<comment><USER2>
      > And how many people had their cassette of the Repo Man  soundtrack eaten by a Walkman?

Wonderful writing.</comment>


A Patient Is Sued, and His Mental Health Diagnosis Becomes Public - <AUTHOR> http://www.nytimes.com/2015/12/24/nyregion/a-patient-is-sued-and-his-mental-health-diagnosis-becomes-public.html <comment></comment>


Eight decades of Helen Levitt's New York City street photography - <AUTHOR> http://dangerousminds.net/comments/kids_play_8_decades_of_helen_levitts_stunning_new_york_city_street_photogra <comment><USER2> I can't even imagine the hassle that a photographer would attract trying to take photos of "other people's kids" in a major western metropolis today.

How times have changed.

</comment><comment><USER3> Really enjoyed seeing the photos, especially the black and white images which likely were taken earlier in Levitt's career vs. color shots. Her style is reminiscent of Henri Cartier-Bresson, who was also working in that era, pretty good company indeed.

Unfortunately the article provided only sketchy info about the artist and the work. I suppose its purpose is prompting readers to find out more about the artists mentioned, certainly it taps into my interests.

</comment><comment><USER4> The absence of parked cars in all but one of these photos is pretty striking.

</comment><comment><USER5> I discovered Helen Levitt's during her exhibition at Fotografiska in Stockholm. Her casual approach to her subjects have inspire me and shows how to use the Leica for real street work. She changed how I view photography as a medium. IMHO she is absolutely in class with her peers of the time; Henri Cartier-Bresson, Walker Evans and Ben Shahn.

</comment><comment><USER6> I knew nothing of her work. Thanks for this.</comment>


Generate Image from Sourcecode? - <AUTHOR>

A while ago there was a site posted that would allow me to paste in source code and it would apply effects to it and generate an image based off that.
I have been searching everywhere for this site, with no luck.
Any chance anybody remembers the link to a site that does this? <comment><USER2> Was it possibly this: [https://github.com/mumrah/source2image](https://github.com/mumrah/source2image)

It looks like it used to be hosted on source2image.info, which is no longer up. I remember what you're talking about, but not the URL. That's the only thing that HNSearch came back with that was relevant.

<comment><AUTHOR> Hmm, I remember for sure that the domain was not that. That is similar to what it was I am looking for, but the version I knew of would apply different effects to it (Similar to themes in Sublime) and slant the text and everything.

So thats a nice start, thanks for sharing that; but it is not quite the one I have in mind

<comment><USER2> Glad you found it.

Hopefully this is you: [http://instacod.es/76758](http://instacod.es/76758) With the unnecessary 4 paddings with the same value and the bad indentation. :)

</comment></comment></comment><comment><USER3> [http://www.momentofgeekiness.com/2013/01/31/instacode- instag...](http://www.momentofgeekiness.com/2013/01/31/instacode-instagram- code/)

The actual site is down. [http://instacode.linology.info/](http://instacode.linology.info/)

<comment><AUTHOR> Looks like its here now: [http://instacod.es/](http://instacod.es/)

</comment></comment><comment><AUTHOR> Thanks for the comments, it has been found!

[http://instacod.es/](http://instacod.es/)</comment>


Subcellular computations within brain during decision-making - <AUTHOR> https://www.sciencedaily.com/releases/2019/11/191114161903.htm <comment> Pick-A-Hill2019 It is late and my head is fuzzy but from the research paper ( [https://elifesciences.org/articles/46966](https://elifesciences.org/articles/46966)) a few things jumped out at me - 'We found that our subtraction procedure, as well as other linear subtraction methods we tested, failed to produce accurate estimates of correlations between spines and the global reference signal'. & 'Inferred correlations between input (spines) and output (soma) did not reliably predict true correlations, even in simple and linear models of the relationship between activity and fluorescence signals in dendritic spines. This was also true for all linear subtraction methods we tested'.</comment>


Ancient never-before-seen viruses discovered locked up in Tibetan glacier - <AUTHOR> https://www.livescience.com/unknown-viruses-discovered-tibetan-glacier.html <comment><USER2> Growing up in the 50s, I loved the 1951 movie _The Thing_. I learned from it to beware of what you find frozen in the ice! Seriously, viruses that we haven't evolved to fight off can be very dangerous.

<comment><USER3> > For the past 15,000 years, a glacier on the northwestern Tibetan Plateau of > China

15k years ago is a pretty small window in our evolution. My baseless assumption would be that we've seen something like it before. And, being "never seen before" could mean that all of the animal life that we know now is completely immune, eradicating it long ago.

I'd be more worried of present/future virus and bacteria that have evolved with us.

<comment><USER4> Well the flip-side of that is there weren't that many humans around circa 13,000BCE and we were geographically isolated. For all we know this virus could have killed the all humans living on the Tibetan Plateau back then.</comment></comment></comment>


Real-time Speech encoding (G711, Speex, AMR in Javascript) - <AUTHOR> http://bamboo.av.it.pt/

<comment><USER2> No need to install/use any app besides my web browser? Well done, sir!

</comment><comment><USER3> Wow... Just. Wow.

</comment><comment><USER4> Nicely done!</comment>


Configurable async web spider in Node.js - <AUTHOR> https://github.com/missinglink/huntsman

<comment><USER2> Why did I have to follow that Wikipedia link!?</comment>


Evan Ratliff's the Mastermind: Drugs. Empire. Murder. Betrayal - <AUTHOR> https://www.timeslive.co.za/sunday-times/books/non-fiction/2019-03-29-extract-evan-ratliffs-the-mastermind-drugs-empire-murder-betrayal/ <comment><AUTHOR> Can't wait to read the book.</comment>


Blockchain: A technical primer - <AUTHOR> https://www2.deloitte.com/insights/us/en/topics/emerging-technologies/blockchain-technical-primer.html <comment><USER2> _A blockchain is a digital and distributed ledger of transactions, recorded and replicated in real time across a network of computers or nodes (figure 1). Every transaction must be cryptographically validated via a consensus mechanism executed by the nodes before being permanently added as a new "block" at the end of the "chain." There is no need for a central authority to approve the transaction, which is why blockchain is sometimes referred to as a peer-to-peer trustless mechanism._

I see this kind of explanation a lot. It's misleading at best. A block chain is most definitely not a ledger, as is claimed by too many sources to count.

A block chain is a tool allowing a group of users to produce a single, unique transaction _log_.

To this end, transactions are grouped into _blocks_. A block references two pieces of information: (1) its ordered list of transactions; and (2) its parent block. Two or more blocks may claim the same block as a parent. Therefore, a collection of blocks can be assembled into a tree with one or more children pointing to a parent.

Each user maintains its own copy of the tree. All paths through the tree are followed and scored. The path with the highest score is designated as the _active chain_.

The active chain is what many people think of when they use the term "Blockchain."

However, the structure of this chain is mostly boring and unremarkable. The most interesting thing about it are transactions. Like blocks, transactions link together. Additionally, transactions run programs that induce global state changes.

The secret sauce of "Blockchain" boils down to incentivizing each user to choose the same active chain in an adversarial environment. The best-tested procedure uses "proof-of-work."

If the relative order of events plays an important part in what you're trying to do, and you operate in an adversarial environment, then a block chain might help.

Otherwise, there's not much a block chain can do for you.

<comment><USER3> I thought a ledger was a transaction log. It was in relation to a ledger I first came by the term transaction (or "trans").

<comment><USER2> You might be thinking of a "journal":

 _Journals and ledgers are where business transactions are recorded in an accounting system. In essence, detail-level information for individual transactions is stored in one of several possible journals, while the information in the journals is then summarized and transferred (or posted) to a ledger. The posting process may take place quite frequently, or could be as infrequent as the end of each reporting period. The information in the ledger is the highest level of information aggregation, from which trial balances and financial statements are produced._

[https://www.accountingtools.com/articles/what-is-the- differe...](https://www.accountingtools.com/articles/what-is-the-difference- between-a-journal-and-a-ledger.html)

A ledger can be created from a journal (transaction log), but then again, many other kinds of things can be created from a transaction log (e.g., the "World Computer" idea for Ethereum).

<comment><USER4> Ah a journal is more like a block. It is transaction with several line items.

This is then transferred into the ledger which is just a list of transactions. Exactly like a blockchain

</comment></comment></comment></comment><comment><USER5> Blockchain is very applicable to industries where middlemen extract large value by being intermediaries between competing parties.

As an example, in telecom there is the issue of settlement. Every phone call generates a Call Data Record (CDR) that has information about who called who, call length, etc. This is critical because every telco negotiates individual rates for voice, SMS, data roaming, etc. between every other carrier on earth (although often you negotiate with one company that provides a package rate for multiple telcos). Your "unlimited" plan obfuscates the fact that how you use your plan, what carriers the people you call are on, where you use data, reflect different levels of profitability for you as a customer.

Large companies like Amdocs[0] make billions of dollars handling settlement for telcos. Every month, a carrier has to "settle" all of their CDR's with every other carrier. Issues get sorted out because CDR's never match perfectly, and then carriers pay each other to balance out based on their contractual obligations.

A blockchain solution that all telcos agreed on would guarantee data correctness (CDR's all look alike), allow instant settlement and payment (settlement happens once a month), and eliminate the middlemen like Amdocs, Synchronoss, etc. in regards to settlement.

Obviously this is a tough problem to crack, and you'd need to get the telcos on board, but I am explaining this as an example where blockchain could provide real value.

Indeed, Maersk, the largest shipping conglomerate, is going to release a blockchain solution to move the international shipping industry away from paper and to a unified system.[1] Maersk is in a unique position to do this because they are the largest player, and most other companies just follow what they do, but I mention this as an example where blockchain can help competing companies interact more efficiently.

[0] [https://www.amdocs.com/](https://www.amdocs.com/)

[1] [https://www.economist.com/briefing/2018/04/26/the-global- log...](https://www.economist.com/briefing/2018/04/26/the-global-logistics- business-is-going-to-be-transformed-by-digitisation)

<comment><USER6> Going from "paper" directly to blockchain, with not a peep about traditional databases.

Surely the executive is just using blockchain as a buzzword for database.

<comment><USER7> How do you make a traditional database immutable? Who controls writes and updates? Well it's a matter of consensus.

<comment><USER8> Blockchains are not immutable - the DAO hack and subsequent hard-fork proved that to the tune of millions of dollars.

<comment><USER9> That was a fork, not a mutation of the database. You can still today go back and see the history play out in the different chains.

</comment></comment></comment></comment></comment><comment><USER10> > In fact, it can be considered one of the biggest technology breakthroughs in > recent history, similar to the advent of the Internet in the early 1990s.

If this were the case, wouldn't we see the technology in the wild more? That seems like a bold claim for something that is still being vetted and explored.

I certainly see value in blockchain but the applications that are using it today don't excite me. The hype puts me off but I am hoping to see it bloom into other areas of software that aren't ICOs or proof of concepts.

<comment><USER11> big changes usually require more time in the adoption phases..autos did at the beginning of the 19th century.

<comment><USER6> Technologies that are actually useful tend to be aggressively adopted by military, academia, industry. Internet and IC engine were.

On the contrary, blockchain finds its activism among SQL-illiterate people, and certainly not the aforementioned groups. Mind that we're already a decade in.

<comment><USER12> With a SQL database, how do you achieve consensus on a proposed transaction without a middleman taking an arbitrary cut of the proceeds?

<comment><USER6> The two parties either agree, or they don't. Full stop. Blockchain, or any buzzword technology, doesn't solve this eternal problem.

Third parties have historically been pretty good at sussing out consensus from the two. Judicial systems, market exchanges, etc.

When you pay a middleman, you are literally paying for Trust-as-a-Service, among other things (brokerage, etc).

Blockchain also costs money to build and maintain as a service, but it's probably the fact that the enormous cost is socialized that makes it an easy pill for many to swallow.

<comment><USER12> Who maintains the source of truth for this record of agreement? If it is one entity, that's the unaccountable middleman. Blockchain is not right for every environment, but there are industries where the middlemen are taking more than the equivalent of every party maintaining a blockchain team.

And court cases are even more expensive.

</comment></comment></comment></comment></comment></comment><comment><USER13> I find this to be less of a whitepaper and more of an opinion piece. For e.g.

"For example, two business parties transacting would not need to maintain their own record of the transaction and would use the blockchain as a single source of truth instead."

Ummmmmm...isn't the whole idea of blockchain that we all have a copy (our version of the truth) and a transaction is validated by several participants or miners? That's basically how we get rid of the middlemen? The sentence is clearly trying to convey that this is somehow more efficient than a current system based on a centralized authority, but there's no actual evidence that this is true.

Blockchain might bring efficiency to an industry like shipping that currently uses a VERY inefficient system, but it's disingenuous to tell others (especially if you are trying to sell something), that it is more efficient than a well implemented centralized system.

</comment><comment><USER14> They explain the basics of permisionless blockchains and they go on and say "Prominent blockchain consortia include Enterprise Ethereum Alliance, R3, and Hyperledger", this can confuse people since R3 and Hyperledger are quite different from a permissionless chain with mining, and the value added of such platforms without crypto-currencies is highly debatable in my opinion.

</comment><comment><USER15> > In fact, it can be considered one of the biggest technology breakthroughs in > recent history, similar to the advent of the Internet in the early 1990s.

Audibly sighing. read this: [https://shkspr.mobi/blog/2018/06/how-i-became- leonardo-da-vi...](https://shkspr.mobi/blog/2018/06/how-i-became-leonardo-da- vinci-on-the-blockchain/)

It's the internet of shit in crypto, all over again. Come on. There's nothing like 50% of the swarm simply declaring your transactions null and void, but that's obviously how the blockchain is currently operating for some ... uh, _criminal_ reason.

</comment><comment><USER16> "technical primer", yeah right.

I guess this counts as "technical" to people at Deloitte.

</comment><comment><USER17> Pretty good primer for newcomers, though it seems to take it as a given that blockchains are (or to hear them say it, "blockchain is") just fully as amazing and applicable as the hype suggests, and here's what you are going to have to do when you inevitably get with the program!

<comment><USER18> This is understandable, given the fact that this is from Deloitte, who would like to sell consulting services.

</comment></comment><comment><USER19> Another amateur's writing about blockchain. If you want the immutability, the blockchain is not immutable, just difficult to modify. Also you only need hash signature for this purpose.</comment>


Data is not an asset, it's a liability - <AUTHOR> https://www.richie.fi/blog/data-is-a-liability.html <comment><USER2> He's on to something here, but I think the asset/liability duality isn't a matter of your point of view. Code really _is_ a liability, even from the high-level view in the boardroom. The asset is functionality. If you can get more functionality with less code, you improve your balance sheet.

By analogy, data is also a liability. The asset is insight.

<comment><USER3> From an accounting perspective I am inclined to disagree. Firstly, the way you present functionality as asset and code as liability, you do not make it easy for me to read how they are components of a balance sheet. More specifically, how do you see your balance sheet improving while still being balanced?

Furthermore, both assets and liabilities (including capital) are stock measures. I would consider insight more of a flow than a stock. More specifically, I think it is the process and tools of achieving insights that is the asset. Whether data is part of this asset base is up for grabs, but accountants have not identified any reasonable way to measure it.

"...the light that falls on to your eye, sensory information, is meaningless, because it could mean literally anything. And what's true for sensory information is true for information generally. There is no inherent meaning in information. It's what we do with that information that matters." Beau Lotto

From a very interesting TED presentation.

[http://www.ted.com/talks/beau_lotto_optical_illusions_show_h...](http://www.ted.com/talks/beau_lotto_optical_illusions_show_how_we_see.html)

And I know I am confusing information with data, but no one has a convincing definition to separate between the two.

<comment><USER4> How about "data is the n-dimensionally measured point and information is data plus some reference and dimensional axes" as a working definition?

<comment><USER3> I don't know if I understand properly, but are the dimensions not implicitly at least defined if we have n-dimensionally measured point? Any additional dimension would be either irrelevant or would be necessitating additional data to populate the dimension

</comment></comment></comment></comment><comment><USER5> The reason to collect everything (or rather, more things than you think you'll need to answer the questions you think you'll need to answer) is that…you could be wrong about what data are required to answer the questions you've identified, and that you could be wrong about which questions you will care about.

And historical data _can_ be extremely useful, e.g. when looking at seasonal or cyclical trends (woe betide the grocer who doesn't stock up on turkeys in mid November, which means woe betide the grocer who doesn't order turkeys in the summer).

Yes, he's _absolutely_ right that data management and privacy impose a cost: the cost of storing a GB of data is more than S3's 10¢. It takes a human being to make a judgement call about whether this data is likely to be worth its overall cost and risk. That's why managers and other decision-makers get paid what they get paid. 'Data is a liability' is a nice soundbite, but it doesn't capture the full reality; one can't manage to soundbites.

<comment><USER6> This is a strange critique. His recommendation isn't a soundbite. It is: ask questions, figure out what you need to know to answer those questions, and then collect that data.

That (asking questions and making informed decisions) sounds like exactly what those "managers and decision makers" ought to be doing in the first place. To collect everything because you can't decide on a strategy is exactly the opposite.

 _(Re: turkeys and fairly complex retail sales cycles. A year or three of aggregated purchase history is likely to yield actionable insight. It 's unlikely that a slight upward trend in turkey purchases since 2006 is very actionable.)_

<comment><USER7> Old data is possibly uninteresting. That's debatable. But all uncollected data is freshly uncollected data.

I strongly believe in collecting as much granular data as possible. It's totally possible to throw it away after it has outlived its likely usefulness.

But if I want to calculate a new machine learning signal today , I can't wait six months to accumulate enough data. I want that data to exist. And the only solution is to overcollect. And to collect at a granular level so I can aggregate and transform later.

The liability and security concerns are real. The fact that most companies are stupid about investing in unnecessary big data infrastructure is real too. But a recommendation to spool to cheap offline or nearline storage immediately is interesting. A recommendation to throw data away seems like folly to me.

<comment><USER6> If your operation is the sort that capitalizes on machine learning on subtle signals, you capture the sorts of data that you know might be beneficial 6 months down the road. Although I suspect that you overstate the sort of "surprise questions" that might come up (and also the granularity necessary to answer them), that is a correct response to a business model that demands those insights at that granularity.

That doesn't mean that "collect everything at max granularity" is good advice, because as you said:

> The fact that most companies are stupid about investing in unnecessary big > data infrastructure is real

<comment><USER8> The fact of the matter is that I've never been unhappy about overcollecting data. Worst case, step 1 of my pipeline is 10x or 50x slower than it needs to be due to filtering out a bunch of junk. The added latency to my workflow might be a few minutes.

Every time I've undercollected I've been unhappy, and this was hardly a rare occurrence. I need to build the collector, deploy it, and wait for data to flow in. Added latency = 1 week, minimum.

You can always throw useless stale data away. You can never retroactively collect data you needed.

</comment></comment></comment></comment></comment><comment><USER9> This article is highly misleading. Sure, certain kinds of data (like credit card data or medical data) can be a liability if not properly managed. If you are working in one of those industries you already know that (although arguably many financial and medical companies underestimate the risks).

In contrast, data about what users have clicked, comments on an online forum, or who has friended who on your social media site is not a liability. In many cases this data is already public. Even in cases where it's not, it is usually incredibly boring for any hacker to steal, like what web pages John Doe has clicked on in the last 10 minutes. Hackers are going to go after stuff like social security numbers or credit card numbers, not data about the average length of time people spent looking at Pepsi Inc. web page layout A versus web page layout B.

The argument that you should only store "the data that you need" is a circular one. How do you know what data you need? Well, you run an analysis. How do you run an analysis? Using the data you have. Short-sighted policies like throwing away historical data, as the article recommends, effectively blind you to long-term trends.

<comment><USER10> The bigger problem is the nature of this sort of data. All of this sort of data needs to be invalidated all the time and provided as some sort of hash rather than actual data that is usable.

<comment><USER11> Check out Enigma [1]. It allows a 3rd party to perform computations on encrypted data using distributed, secure multi-party computations.

Thing is it's at least 20x slower than computing over plaintext, and nodes will have to be compensated with fees, much like Bitcoin miners.

Still, for safety critical industries, this could be a very useful tool. Especially if the government steps in and mandates such a protocol.

Here's a more in-depth write-up I did a few weeks back if you're interested: [https://www.linkedin.com/pulse/iot-use-cases-enigma- homomorp...](https://www.linkedin.com/pulse/iot-use-cases-enigma-homomorphic- encryption-roy-murdock?trk=prof-post)

[1] [http://enigma.media.mit.edu/enigma_full.pdf](http://enigma.media.mit.edu/enigma_full.pdf)

</comment></comment></comment><comment><USER11> It depends on what industry you're in.

So JPMorgan took a bit of a reputation hit when hackers compromised the data of 83m of the company's clients. [1] The financial repercussions were minimal, if there even were any to begin with. You can bet they still collect and store all the data they can. They don't really care, and customers don't really care all that much either.

On the other hand, we have medical data, which is essential for pharmaceutical and academic research but would be very, very harmful in the wrong hands. A non-compliant company will get smacked with heavy fines under HIPAA for not safeguarding data in a strict, standardized manner.

Until government regulation makes data breaches substantially costly for Company X (Target, Adobe, LastPass, Department of Personnel Management, etc.), Company X will continue to gather as much data as possible.

It's an asset with unbounded upside (who knows what great economic engine data might fuel in 5-10 years) and no financial downside because it carries no legal risk, and very minimal storage costs.

[1] [http://dealbook.nytimes.com/2014/12/22/entry-point-of- jpmorg...](http://dealbook.nytimes.com/2014/12/22/entry-point-of-jpmorgan- data-breach-is-identified/?_r=0)

</comment><comment><USER12> >>Think this way for a while, and you notice a key factor: old data usually isn't very interesting. You'll be much more interested in what your users are doing right now than what they were doing a year ago. Sure, spotting trends in historical data might be cool, but in all likelihood it isn't actionable. Today's data is.

Uhhhh, really? There have been a lot of times in my past where, as an analyst, I wished I had an bunch of historical data to measure the seasonality of trends. Am I the only one who baulks at this comment? Is this a startup- oriented perspective?

</comment><comment><USER13> Cultural difference: In US, your customer DB is an asset like anything else. In EU, your customer database is a liability.

<comment><USER14> One could, cynically, break it down to

> In the US, your customers are an asset. In the EU, your customers are people > with rights

because that's what this is about. And I, personally, have to fully support the EU view here, which is that the privacy of a person is more important than the profits of a company.

</comment></comment><comment><USER15> Another way of looking at the article is that it's more important to have the _right_ data than just having lots of data. So it's very important to think about the questions that one would want to answer and design data collection to capture the answers, rather than just going ahead and storing everything in a brute force way.

<comment><USER16> But having lots of data improves your chances of having the right data _when you figure out what it is_.

<comment><USER17> Like all the data the NSA, TSA, and FBI dragnet stopped 9/11, the Boston bombings, Christian terrorists shooting up doctors and churches?

Oh, no, it doesn't. Not least because there's so much data even they have trouble working out what to do with it all.

<comment><USER14> One of the arguments during the Bostom bombings was that "if Boston had, like NYC, a fully integrated CCTV system automatically filming everything and allowing to track people across the city, we could have found the attackers more easily".

One has to seriously think about this. We, as a society, are signing away some of our most important rights for a statistically insignificant boost in security.

I live in Germany, but even here we still feel these changes, which were started with 9/11.

It's now the 14th anniversary of 9/11, and I have to say, long-term, Bin Laden has won. The western world has given up so many rights for the war on terrorism.

Giving up privacy just to collect more data, so we feel safer (while the data is just thrown away) is just another step where we forget that people are actually, well, people. With rights.

</comment></comment></comment></comment><comment><USER18> A $125 billion market for big data solutions is NOT a sign that data is a liability. What is the value of that data?

I'm also skeptical of the compliance/privacy argument. If you're collecting any data at all, it's a potential liability. The volume of the data doesn't change the risk level much.

<comment><USER19> False premise.

This assumes that:

1\. The externalities cost of data exposure is fully realised. What is Ashley Madison's liability for suicides of members attributed to its data leak? Or of the _multi-generational_ impacts of fractured families (immediate plus affected children, possibly parents of spouses who split on account of the breech). A frequently leveled compaint about "remediation" for data disclosure is that it does little to address the full costs to those victimised by it.

AM is all the more interesting in that, as Annalee Newitz's investigative reporting reveals: not only were personal data collected, but (at least for straight males), it _wasn 't_ for the stated purpose: "Ashley Madison created more than 70,000 female bots to send male users millions of fake messages, hoping to create the illusion of a vast playland of available women." In fact, it was a feeder system to a set of bots, "affiliates", and, it seems, escort services.

[http://gizmodo.com/ashley-madison-code-shows-more-women- and-...](http://gizmodo.com/ashley-madison-code-shows-more-women-and-more- bots-1727613924)

2\. It assumes the market is rational. Enron's market capitalisation was $60 billion on December 31, 2000, prior to its collapse. The share price fell from $0.75 to less than one dollar by November, 2001, its bankruptcy filing was dated December 2, 2001.

The larger problem: what is seen cannot be unseen.

An exceptionally peculiar aspect of digital data is that, while it may remain in the boxes and cages provided for it, it's got a notable tendency to find itself liberated. Often without warning, and not detected for days, weeks, months, or longer, afterward (as in this case). In the real world we've got friction, especially associated with data processing and transfer. In digital form, far less so. Sometimes friction is good.

Finally: that's the market for _tools to analyse the data_ , not for the data itself. Big Data is a current business fad. Companies are told they must capitalise on Big Data, so they buy miracle solutions to do that. Some can, and in cases spectacularly. Many cannot -- the added value-per-customer is small, or, in the case of breach, negative.

<comment><USER20> _1\. The externalities cost of data exposure is fully realised._

No, it only says that _because_ it isn't fully realised, the data is not a liability as it would be otherwise.

</comment></comment></comment><comment><USER19> I'm quite happy to see others starting to recognize this. It's a problem, as someone who's dealt with "big data" since the early 1990s, that I've been quite well aware of for several decades.

An exceptionally peculiar aspect of digital data is that, while it may remain in the boxes and cages provided for it, it's got a notable tendency to find itself liberated. Often without warning, and not detected for days, weeks, months, or longer, afterward (as in this case). In the real world we've got friction, especially associated with data processing and transfer. In digital form, far less so. Sometimes friction is good.

What you almost always want to do is to _roll data up to non-individualised aggregates_ as soon as practically possible. The rest is just dry powder waiting for a spark.

[https://www.reddit.com/r/dredmorbius/comments/3hn4r5/on_the_...](https://www.reddit.com/r/dredmorbius/comments/3hn4r5/on_the_media_asks_what_can_we_learn_from_ashley/)

</comment><comment><USER21> Totally agree. Was going to add that an expanding schema is a liability but that seems self evident with the comments about code expansion.

If you've ever built a very busy application you know the truth of this. At first the massive access to data you have seems like a gift and you'll log it all "just in case". You might even brag about the volumes of data you have and speculate about their value to investors and internally. But eventually you realize the risk and cost and cost of managing the risk.

</comment><comment><USER22> _Private customer data_ often includes a liability, but not for the reasons that OP states. The liability is that companies have an ongoing obligation to their customers to protect their private data. However, a lot of data does not have this liability. If it gets published to the world, it wouldn't matter.

This article portrays a common misunderstanding of the accounting terms liability and asset. Just because something has a cost to maintain, it does not make it a liability.

Code is an asset. Data is an asset. Businesses do not value assets at their cost, as the article represents, but in their future economic value.

Asset:

"Things that are resources owned by a company and which have future economic value that can be measured and can be expressed in dollars. Examples include cash, investments, accounts receivable, inventory, supplies, land, buildings, equipment, and vehicles."

Liability:

"Obligations of a company or organization. Amounts owed to lenders and suppliers. Liabilities often have the word "payable" in the account title. Liabilities also include amounts received in advance for a future sale or for a future service to be performed."

<comment><USER23> _A liability can mean something that is a hindrance or puts an individual or group at a disadvantage, or something someone is responsible for, or something that increases the chance of something occurring (i.e. it is a cause)._

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

</comment></comment><comment><USER24> This is one reason we decided at Cotap to purge messages after 14 days by default, and only keep them longer if requested ([https://cotap.com/blog/customizable-data-retention-for- busin...](https://cotap.com/blog/customizable-data-retention-for-business- messaging)). Contrary to what one might expect, most users embraced the change.

</comment><comment><USER25> Somewhat in this vein:

Years ago I worked at a large advertising network that was concerned about fraudulent impressions. E.g. Ads placed "under the fold" or hidden or behind stuff or otherwise generating impressions that weren't real.

I suggested we could build a small piece of supplemental ad code that would load alongside one of our ads in a row page and "look around" — see where ads were placed and so on.

The idea was rejected because it would create too much data. I argued that we could trigger the fraud detection code once per n impressions with n being 100 or 1000 and still be able to identify fraudulent sites with statistical certainty (our problem would be false negatives) but they couldn't wrap their heads around merely sampling enough data to answer a question rather than ALL the data, so the idea was rejected.

Of course it's also highly likely that they didn't actually want to detect fraud.

</comment><comment><USER26> "Then you collect the data you need (and just the data you need) to answer those questions."

If you are providing something to anonymize activity- then sure, if it is legal. And you want to store as little data as possible that would be hazardous if it was made public. But for everything else, it's probably not a good idea to have this attitude.

There are many questions you don't need to answer before you need them, and then it would be good or even necessary to have them historically. For example, auditing changes made to the system or data, logging some requests and responses, tracking user behavior for analysis by marketing, etc. Over time, depending on the site/service, you may want all those things and more.

</comment><comment><USER27> Maybe you don't have the resources to analyze the data today, but you still need to collect it for when you do. A history of data can give you a null hypothesis to work with. When we see a drop in traffic in August is it because we're losing relevance, or because August tends to be a slow month.

</comment><comment><USER28> Data is absolutely an asset. All decisions are driven by data (could be personal, biased, anecdotal, etc.), so why not make decisions based on more data points? It's cute to think you can "ask questions first, then collect" but this wastes time in 2015. Imagine being asked at Netflix "calculate the % watch through of 18-21 year olds for kids movies", then a week later "for action movies in the 1980s. As opposed to having the viewing info for all your users before these questions arise.

BTW, users DO want you to use their data to improve your service. Otherwise google, facebook, twitter, netflix, etc. would not be as successful as they are. Liability only comes into play when OTHER parties access (legally or illegally) your data.

<comment><USER14> Well, this collecting data is exactly why the US tech industry is considered to be reckless with privacy and safety of data.

And lawcases have shown that the "we record everything" in the ToS is legally null and void – only stuff the user directly expects to be recorded are legal.

If you are a flashlight app, and in your ToS is "we'll send all your contacts to a third-party company", then this is void, and if you do so, the user can sue you. As has happened with Facebook in the EU several times.

This reckless "we'll record everything" is why the EU is planning their new "you can't record anything unless directly allowed to, and you can not sell it or give it away to any third-party entities, not even governments" law. (Well, the last part was thanks to the NSA).

This attitude hurts the US tech industry.

<comment><USER28> I am perfectly fine with that, in fact I expect it when using services like google and facebook. I expect that facebook is crunching my data and feeding me ads, while the advertisers never see who I am or what I'm about.

<comment><USER14> Well, it's simple: If people are outraged when you tell them what facebook actually stores, then it's not okay.

And the outrage exists.

I do not think anyone should store anything about me unless I explicitly want to give it to them.

One example is Google's horrible traffic tracking system. In my city every lane of every intersection has a separate inductive loop to measure traffic congestion, speed and amount. Also every few hundred meters between intersections. Perfect data, and you only collect as much as necessary.

In comparison, Google's system: Track the location of everyone, and then check if people are moving slowly on a road in a car.

One of these stores an Orwellian amount of information, the other stores just as much as necessary.

Anyway, as a German, I hate this type of data collection. Yes, I openly admit, I hate the business model of the US startup industry. And I hope this fad stops very soon, as currently we have a truly dystopian nightmare of data collection.

Just think about what a less-democratic government could do if they'd get elected in the US in a few years. They could seize Google's data, force them to comply (like the NSA already did) and then use the data against the people.

You have location data of almost everyone, and not just for now, but for every day for the past 5 years. With 5 minutes accuracy. You have banking data and access, emails, browser and search history.

This is too much power that rests in a single place. Potential for abuse is insane.

</comment></comment></comment></comment><comment><USER29> It's definitely an asset, but it's potentially a dangerous one. It might be like owning enriched uranium fuel pellets. Extremely valuable asset that can power a society, but dangerous if it falls into the wrong hands or is allowed to contaminate the environment.

</comment><comment><USER30> Public data is an asset. Private data is a liability.

<comment><USER31> > Public data is an asset. Private data is a liability.

I think, more precisely:

 _Useful_ data is an asset. _Legally sensitive_ (e.g., because of privacy laws) data is a liability. Those categories overlap, and data in the overlap may be a net asset or a net liability depending on the specific utility it provides balanced against the costs (both certain compliance costs and risks) associated with the specific legal protections.

This isn't really unusual -- the same thing is true of pretty much everything a business (or individual) might own. Real estate, for instance, is an asset to the extent that it is useful, but owning (or even possessing as a tenant) real estate comes with certain maintenance costs _and_ liability-related risks.

</comment></comment><comment><USER32> First, hat-tip to Marko for running a business with integrity. I really like the parallel between data and finance as it relates to privacy.

As it turns out, banks have a very similar history of making promises & violating them. There are many parallels between banks & debt and data & technology.

I wrote a post titled "Silicon Valley Data is the New Wall Street Debt" that you folks may like:

[http://livefreeortry.com/2014/04/30/silicon-valley-data- is-t...](http://livefreeortry.com/2014/04/30/silicon-valley-data-is-the-new- wall-street-debt/)

</comment><comment><USER33> I think this is a pretty good, general rule. But with everything in technology it's not true for everything. For instance auditing and medical records. Basically the only exceptions are going to be things not actionable in the market.

Good read!

</comment><comment><USER34> If data is a liability aren't we all worse off for knowing that?

<comment><USER23> I read an interesting book once that distinguished clearly between data, information, wisdom and perhaps a couple of other levels of this hierarchy. Advice is usually not _data_. Data is raw, unprocessed information. Being awash in it is not necessarily valuable, but wisdom is a different matter altogether.

<comment><USER35> DIKW Pyramid [https://en.wikipedia.org/wiki/DIKW_Pyramid](https://en.wikipedia.org/wiki/DIKW_Pyramid) Now your turn. What's the name of the book? :)

<comment><USER23> Thanks!

Unfortunately, I don't recall the name.

</comment></comment></comment></comment><comment><USER36> you make it work for you -> it's an asset. You leave it laying there doing nothing -> it's a liability.

Perspective people.

</comment><comment><USER37> Well, Asset = liability + owner contribution. /s

</comment><comment><USER38> Data are an asset. Data custodians are the liability.

</comment><comment><USER39> TL;DR

Don't collect or store data you don't need yet.

</comment><comment><USER40> This reminds me of the RadioShack bankruptcy. I don't think the bankruptcy process was designed for "selling" personal data, right?

</comment><comment><USER41> Folks, Big data can cure cancer. Big data can also start world peace. Google it. I'm srs.

</comment><comment><USER42> This person doesn't know much about data.</comment>