Announcing the first SHA-1 collision - <AUTHOR> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html <comment><USER3> The visual description of the colliding files, at [http://shattered.io/static/pdf_format.png](http://shattered.io/static/pdf_format.png), is not very helpful in understanding how they produced the PDFs, so I took apart the PDFs and worked it out.

Basically, each PDF contains a single large (421,385-byte) JPG image, followed by a few PDF commands to display the JPG. The collision lives entirely in the JPG data - the PDF format is merely incidental here. Extracting out the two images shows two JPG files with different contents (but different SHA-1 hashes since the necessary prefix is missing). Each PDF consists of a common prefix (which contains the PDF header, JPG stream descriptor and some JPG headers), and a common suffix (containing image data and PDF display commands).

The header of each JPG contains a comment field, aligned such that the 16-bit length value of the field lies in the collision zone. Thus, when the collision is generated, one of the PDFs will have a longer comment field than the other. After that, they concatenate two complete JPG image streams with different image content - File 1 sees the first image stream and File 2 sees the second image stream. This is achieved by using misalignment of the comment fields to cause the first image stream to appear as a comment in File 2 (more specifically, as a sequence of comments, in order to avoid overflowing the 16-bit comment length field). Since JPGs terminate at the end-of-file (FFD9) marker, the second image stream isn't even examined in File 1 (whereas that marker is just inside a comment in File 2).

tl;dr: the two "PDFs" are just wrappers around JPGs, which each contain two independent image streams, switched by way of a variable-length comment field.

<comment><USER4> Great analysis. So why did Google choose to use PDFs instead of JPGs directly?

<comment><USER3> The notion of "document security" is a common desire in business and legal contexts. PDFs are a standard representation of documents, whereas JPGs are less common (TIFF might count since it's a somewhat common scanned document format, but I digress).

Subverting the most popular document format, one which even provides built-in support for digital signatures is probably much more interesting than subverting the JPG format.

Open challenge: build two signed PDFs with identical signatures and different contents - it's not necessarily hard, and it would definitely drive the point home.

<comment><USER5> I wonder if this is the 'standard' thing to do when you have a broken hash function. I took a introductory course in computer security a year ago and we had to create MD5 hash-colliding documents for homework[0].

[0] [https://courses.engr.illinois.edu/cs461/sp2015/static/proj1....](https://courses.engr.illinois.edu/cs461/sp2015/static/proj1.pdf) (see part 4)

<comment><USER6> I'm interested in taking a look at this assignment for my own learning, but it looks like there are a bunch of files you need. It would be cool if you put them in a git repo!

</comment></comment></comment></comment></comment><comment><USER7> To put things into perspective, let the Bitcoin network hashrate (double SHA256 per second) = B and the number of SHA1 hashes calculated in shattered = G.

B = 3,116,899,000,000,000,000

G = 9,223,372,036,854,775,808

Every three seconds the Bitcoin mining network brute-forces the same amount of hashes as Google did to perform this attack. Of course, the brute-force approach will always take longer than a strategic approach; this comment is only meant to put into perspective the sheer number of hashes calculated.

<comment><USER8> A few considerations though:

\- Google used GPUs, much of the Bitcoin network relies on fully custom ASICs now and mining without them isn't really profitable anymore

\- SHA1 hashes can also be computed over twice as fast as SHA256 even on GPUs, so if someone were to go out and build SHA1 ASICs, you could probably do this very, very fast. It's almost certain that intelligence agencies could invest this effort to say, break SHA1 SSL certs.

<comment><USER9> _It 's almost certain that intelligence agencies could invest this effort to say, break SHA1 SSL certs._

To the contrary, it is unlikely that they can do so.

There is a world of difference between "come up with two things that hash to the same value" and "come up with something that hashes to a particular known value". It gets harder still if you're trying to add constraints about the format of your text (such as making them look like a potentially valid SSL cert).

To illustrate the difference, suppose that you can constrain the algorithm to produce one of a trillion values. If you generate a million possibilities, odds are good that 2 of them will have the same hash value. You've generated a collision! But you need to do a million times as much work to have good odds of generating any particular value.

That said, attacks only improve over time. While it is highly unlikely that intelligence agencies can break SHA1 certs today, it is extremely likely that they will eventually. Where eventually is 5-20 years.

<comment><USER8> > There is a world of difference between "come up with two things that hash to > the same value" and "come up with something that hashes to a particular > known value".

Doesn't the PDF on their site pretty much prove they can do both of these - <USER2> least, in a way? They were able to change the color without impacting the contents of the PDF and get the same SHA1.

They probably have a fair bit of garbage data to work with in the PDF format, but it seems likely that you might be able to do similar in certificate formats.

Remember, you only need a very small modification to change a valid web cert into a CA cert or a global wildcard.

<comment><USER10> No. I don't know the details of the attack, but a third possibility (as I read it) is that _both_ PDF documents are modified in the process until they arrive at a collision.

PDF has the convenient property that you can inject arbitrary bogus data into the middle of it with a constant head and tail and it will still be valid. The tail of the file contains a trailer that points to the dictionary that describes where all of the resources in the file are located. The entire file need not be covered by the dictionary (and typically won't be for PDFs that have gone through several rounds of annotation/modification). This leaves the opportunity "dead chunks" that can be modified arbitrarily without changing the rendered result.

<comment><USER11> Or, if you're really clever - and Ange Albertini is quite good at this kind of trick - you can design the PDF so that the different garbage in the middle causes the other, unchanged content to be interpreted differently in the two PDF files, possibly even designing it so that the intended contents of each PDF is treated as garbage and ignored entirely in the other PDF.

<comment><USER12> With many image formats, you can just concatenate whatever you want at the end of the file, and the OS and programs will obliviously read and copy the whole file, while the image libraries will happily ignore the extra data.

<comment><USER13> And then you put PHP tags in that content at the end, and change the .htaccess file to process *.jpeg as PHP scripts, and your webshell looks benign until someone has that in mind looking through the account.

<comment><USER14> You don't need to find a collision to do that :)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is malware free, another that isn't.

Release the clean one and let it spread for a day or two. Then join the torrent, but spread the malware-hosting version. Checksums would all check out, other users would be reporting that it's the real thing, but now you've got 1000 people purposely downloading ransomware from you- and sharing it with others.

Apparently it costs around $100,000 to compute the collisions, but so what? If I've got 10,000 installing my 1BTC-to-unlock ransomware, I'll get a return on investment.

This will mess up torrent sharing websites in a hurry.

Edit: some people have pointed out some totally legitimate potential flaws in this idea. And they're probably right, those may sink the entire scheme. But keep in mind that this is one idea off the top of my head, and I'm not any security expert. There's plenty of actors out there who have more reasons and time to think up scarier ideas.

The reality is, we need to very quickly stop trusting SHA1 for anything. And a lot of software is not ready to make that change overnight.

<comment><USER16> Malware in a video? Is that possible? How does it work?

<comment><USER17> You could have a buffer overflow attack talking advantage of a specific popular video player out there.

Since video players are usually not very security focused, someone determined could do it.

And since video torrents are unzipped, a single chunk can be replaced with the malicious chunk with the attack code. It can look like a tiny jitter depending on the chunk size/total video size.

<comment><USER18> You could just do this with a video you release anyways, and skip the century of GPU runtime.

This break requires you control/generate both the original and the evil file.

<comment><USER19> My thought exactly, although you would need your malware to incubate for some time to allow it to spread properly first.

<comment><USER20> I wonder if you could model this similarly to populations. As in will the malware ever go extinct? Obviously an attacker probably won't stop seeding, but let's say shim does stop seeding. At this point x% of seeders have the payload. Seeders on average share the file y times. Will x tend to zero below a threshold of 50%?

And if the attacker does not stop seeding, will the infected quota stabilize?

</comment></comment></comment></comment></comment></comment><comment><USER21> On a quick scroll of the comments, I haven't seen this posted so far: [http://valerieaurora.org/hash.html](http://valerieaurora.org/hash.html)

We're at the "First collision found" stage, where the programmer reaction is "Gather around a co-worker's computer, comparing the colliding inputs and running the hash function on them", and the non-expert reaction is "Explain why a simple collision attack is still useless, it's really the second pre- image attack that counts".

<comment><USER22> Love this page. Someone should remind her to update the table for sha1 now.

<comment><USER23> It seems to have been updated already.

</comment></comment></comment><comment><USER24> This point seems to be getting re-hashed (no pun intended) a lot, so here's a quick summary: there are three kinds of attacks on cryptographic hashes: collision attacks, second-preimage attacks, and first-preimage attacks.

Collision attack: find two documents with the same hash. That's what was done here.

Second-preimage attack: given a document, find a second document with the same hash.

First-preimage attack: given an arbitrary hash, find a document with that hash.

These are in order of increasing severity. A collision attack is the least severe, but it's still very serious. You can't use a collision to compromise existing certificates, but you can use them to compromise future certificates because you can get a signature on one document that is also valid for a different document. Collision attacks are also stepping stones to pre-image attacks.

UPDATE: some people are raising the possibility of hashes where some values have 1 or 0 preimages, which makes second and first preimage attacks formally impossible. Yes, such hashes are possible (in fact trivial) to construct, but they are not cryptographically secure. One of the requirements for a cryptographically secure hash is that all possible hash values are (more or less) equally likely.

<comment><USER25> The severity between the preimage attacks depends on context.

For Git, for example, a first-preimage attack won't buy you anything, but a second-preimage could be potentially devastating depending on how lucky you get.

If Mallory wanted to make it look like you signed a document you didn't, second-preimage would be devestating. And with the demonstration of two PDFs sharing the same hash, this is a pretty severe one: many PGP signatures, for example, still use SHA-1. But even so, you could take some signature from any point in the past.

<comment><USER26> If you can do a first-preimage attack, you can do a second-preimage attack. Just hash the document you have. Therefore a first-preimage attack is strictly more severe.

<comment><USER27> mikegerwitz is technically right. As an illuminating example, consider a hash- algorithm in which there's at least one hash that occurs precisely once. Then a 2nd-preimage attack is formally impossible no matter how much computational power you have (assuming by "second" you meant "distinct second"). But a 1st- preimage attack is formally possible.

<comment><USER24> One of the requirements for a hash to be cryptographically secure is that all possible values are equally likely. So yes, it is possible (in fact trivial) to construct a hash of the sort you describe, but such a hash would not be cryptographically secure to begin with.

<comment><USER28> It's easier to use and to reason about a uniform hash, but you can design a secure system with a non-uniform hash.

I'd be willing to bet that an altered version of SHA3-256 that replaces four bits in the middle with length%16 is better for most purposes than SHA256, despite being non-uniform.

</comment></comment></comment></comment></comment></comment><comment><USER29> I am a bit saddened that Vegard Nossum's work, which they used for encoding SHA-1 to SAT, is only mentioned as a footnote. The github code is at

[https://github.com/vegard/sha1-sat](https://github.com/vegard/sha1-sat)

and his Master Thesis, whose quality is approaching a PhD thesis is here:

[https://www.duo.uio.no/bitstream/handle/10852/34912/thesis-o...](https://www.duo.uio.no/bitstream/handle/10852/34912/thesis- output.pdf)

Note that they also only mention MiniSat as a footnote, which is pretty bad. The relevant paper is at

[http://minisat.se/downloads/MiniSat.pdf](http://minisat.se/downloads/MiniSat.pdf)

All of these are great reads. Highly recommended.

</comment><comment><USER30> Linked [http://shattered.io/](http://shattered.io/) has two PDFs that render differently as examples. They indeed have same SHA-1 and are even the same size.

      $ls -l sha*.pdf
      -rw-r--r--@ 1 amichal  staff  422435 Feb 23 10:01 shattered-1.pdf
      -rw-r--r--@ 1 amichal  staff  422435 Feb 23 10:14 shattered-2.pdf
      $shasum -a 1 sha*.pdf
      38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-1.pdf
      38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-2.pdf

Of course other hashes are different:

      $shasum -a 256 sha*.pdf

      2bb787a73e37352f92383abe7e2902936d1059ad9f1ba6daaa9c1e58ee6970d0  shattered-1.pdf
      d4488775d29bdef7993367d541064dbdda50d383f89f0aa13a6ff2e0894ba5ff  shattered-2.pdf

      $md5 sha*.pdf

      MD5 (shattered-1.pdf) = ee4aa52b139d925f8d8884402b0a750c
      MD5 (shattered-2.pdf) = 5bd9d8cabc46041579a311230539b8d1

<comment><USER31> The PDF example given is somewhat ridiculous.

"For example, by crafting the two colliding PDF files as two rental agreements with different rent, it is possible to trick someone to create a valid signature for a high-rent contract by having him or her sign a low-rent contract. "

Talk about ridiculous scenarios only people living in a tech bubble could come up with.

How many landlords do you imagine know what sha-1 checksums even are, let alone would try and use it as proof the evil version of the rental agreement is incorrect?

"I would have gotten away with it, if it wasn't for you meddling kids and your fancy SHA-256 checksums!"

<comment><USER32> This is not as far fetched as you think.

In UK, rental contracts are often digitally signed by the renter and landlord.

I am sure in finance world many other types of contracts are signed digitally, also under the assumption that both parties sign the same thing.

<comment><USER33> The "signing" usually doesn't involve any cryptography. You just express your agreement, which can be as trivial as typing your initials in a box.

It's purely a legal, not technical thing, so if you cleverly forge the document using collisions, you'll be shouting "but the SHA-1 matched!" from behind the bars.

<comment><AUTHOR> The legal thing does make reference to the technical thing in Europe[1] (and probably elsewhere too), by making digital signatures (which use crypto) legally binding. The question is more how courts would rule in a case where a colliding document is signed. That would probably depend on whether you can prove which of the two parties authored the colliding document (since that's a requirement for this particular attack).

(Note: I don't know whether this attack is practical for qualified electronic signatures as used by EU countries.)

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

</comment></comment></comment></comment></comment><comment><USER34> Big things affected:

* DHT/torrent hashes - A group of malicious peers could serve malware for a given hash.

* Git - A commit may be replaced by another without affecting the following commits.

* PGP/GPG -- Any old keys still in use. (New keys do not use SHA1.)

* Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many).

Edit: Yes, I understand this is a collision attack. But yes, it's still a attack vector as 2 same blocks can be generated now, with one published, widely deployed (torrent/git), and then replaced at a later date.

<comment><USER35> None of what you mentioned is affected since this is a collision attack. They purposely created 2 files with the same hash.

Creating a file with the same hash as legit file is a preimage attack and is much more difficult to perform (many orders of magnitude more difficult).

This still doesn't mean that SHA-1 isn't dogshit however. It should have been phased out years ago.

<comment><USER34> Create 2 torrents with the same hash.

Release one into the wild.

Wait.

Infect.

<comment><USER36> Torrents have a tree of hashes for the parts. That allows validating pieces without the entire file (which is also validated at the end).

Probabilistically, the hashes of the parts would _not_ match even if the top level hash matched.

<comment><USER37> You could (try to) collide one of the blocks at the end of the tree. The tree of hashes will still be the same since the hash of the block didn't change.

Then join the torrent with a client that doesn't download but only upload that block (there will be some that will pick it from you). Many legit copies, except for those that were so unlucky to fetch the block from you.

If you manage to build such a block based on one in recurring content (eg. a distributor's logo at the beginning of the file), it could be reused, too.

<comment><USER36> > You could (try to) collide one of the blocks at the end of the tree. The > tree of hashes will still be the same since the hash of the block didn't > change.

Except you can't do that as this isn't a preimage attack. You can't create an arbitrary bad file matching an existing SHA-1 with this.

<comment><USER38> On the other hand it's useful for denial of service. If you want to disrupt a swarm feeding it bad data is 'good enough'.

<comment><USER36> > On the other hand it's useful for denial of service. If you want to disrupt > a swarm feeding it bad data is 'good enough'.

No you can't do that either. Again, this is _not_ a preimage attack: [https://en.wikipedia.org/wiki/Preimage_attack](https://en.wikipedia.org/wiki/Preimage_attack)

That means you can't use this to match an arbitrary SHA-1. That means you can't use it to generate bad parts of a larger file.

What you're describing is already possible by having clients connect to a swarm, pretend they have parts of a file, and send gibberish. The receiver won't know until they finished downloading the part and hence waste the part- size in download capacity (i.e. DOS). I bet with IPv6 it'd be really easy to have a single malicious client pretend to be a world of swarm members.

<comment><USER38> Thanks, so it can gen 2 same size colliding chunks, but it can not take an arb chunk and generate a collision for it. Right?

<comment><USER36> Yes that's my understanding of it. In the PDF example on the site, the file format allows enough tweaking to the raw data without impacting the content to make it feasible.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER39> Someone just made about $2500

See [https://lists.linuxfoundation.org/pipermail/bitcoin- dev/2013...](https://lists.linuxfoundation.org/pipermail/bitcoin- dev/2013-September/003253.html) and [https://bitcoinchain.com/block_explorer/address/37k7toV1Nv4D...](https://bitcoinchain.com/block_explorer/address/37k7toV1Nv4DfmQbmZ8KuZDQCYK9x5KpzP)

<comment><USER40> That would offset a very, very tiny fraction of the cost of 56,940,000 CPU hours and 963,600 GPU hours.

<comment><USER41> The person who collected it was most likely not a Google employee; just the first person to download those files who knew about the bounty.

</comment></comment></comment><comment><USER42> I love the fact that there is a tool for detecting any collision using this algorithm: [https://github.com/cr- marcstevens/sha1collisiondetection](https://github.com/cr- marcstevens/sha1collisiondetection)

and it's super effective: _The possibility of false positives can be neglected as the probability is smaller than 2^-90._

It's also interesting that this attack is from the same author that detected that Flame (the nation-state virus) was signed using an unknown collision algorithm on MD5 (cited in the shattered paper introduction).

</comment><comment><USER43> [2012] Schneier - When Will We See Collisions for SHA-1?

[https://www.schneier.com/blog/archives/2012/10/when_will_we_...](https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html)

Pretty close in his estimation.

<comment><USER44> Schneier predicted "between 2018--2021 depending on resources". He explicitly says "Since this argument only takes into account commodity hardware and not [...] GPUs". Since Google used GPUs that very well explains the speedup to 2017.

</comment></comment><comment><USER45> I'm trying to play with this in git. Added the first file, committed, and then overwrote the file with the second file and committed again. But even when cloning this repository into another directory, I'm still getting different files between commit 1 and 2. What does it take to trick git into thinking the files are the same? I half expected "git status" to say "no changes" after overwriting the first (committed) pdf with the second pdf?

<comment><USER46> This is because git adds a header and zlib compresses the PDFs such that they no longer collide when stored in git. But of course, they still collide when extracted from git:

        $ ls -l; for i in 1 2; do sha1sum < shattered-$i.pdf; \
        git cat-file -p $(git hash-object -w shattered-$i.pdf) |
        sha1sum; done; find .git/objects -type f -print0 | xargs -0 ls -l
        total 1664
        -rw-r--r--@ 1 jay  staff  422435 Feb 23 10:32 shattered-1.pdf
        -rw-r--r--@ 1 jay  staff  422435 Feb 23 10:32 shattered-2.pdf
        38762cf7f55934b34d179ae6a4c80cadccbb7f0a
        38762cf7f55934b34d179ae6a4c80cadccbb7f0a
        38762cf7f55934b34d179ae6a4c80cadccbb7f0a
        38762cf7f55934b34d179ae6a4c80cadccbb7f0a
        -r--r--r--  1 jay  staff  381104 Feb 23 10:41 .git/objects/b6/21eeccd5c7edac9b7dcba35a8d5afd075e24f2
        -r--r--r--  1 jay  staff  381102 Feb 23 10:41 .git/objects/ba/9aaa145ccd24ef760cf31c74d8f7ca1a2e47b0

See "Object Storage" for details at [https://git-scm.com/book/en/v2/Git- Internals-Git-Objects](https://git-scm.com/book/en/v2/Git-Internals-Git- Objects)

It's worth noting that either of the changes, adding a header or deflating the content, would remove the collision. The former because this is a chosen- prefix collision attack, the latter because the compression alters the content entirely.

I'm not a cryptographer, so I wonder: do the git header and zlib compression add significant complexity to manufacturing two files that collide inside git?

<comment><USER21> The compression is applied after the hashing, so it doesn't make any difference. Only the "blob <size>" header matters.

</comment></comment></comment><comment><USER47> I'm confused by the "File Tester" at [https://shattered.it/](https://shattered.it/)

It says "Upload any file to test if they are part of a collision attack."

When I upload either of their two sample collision documents, it says they are "Safe."

<comment><USER48> I get "Collision found". Couldn't even begin to guess what's causing it to say it's safe on your end, unless you modified the files.

</comment></comment><comment><USER49> For those of us who are totally clueless about the construction of these hash functions, what is the fundamental flaw in SHA-1 that allows this attack? How do newer hash functions avoid it?

<comment><USER50> The newest SHA members are based on sponge functions. [http://keccak.noekeon.org/](http://keccak.noekeon.org/) gives a good overview.

<comment><USER49> Thank you, great link.

</comment></comment></comment><comment><USER51> Computing a collision today costs about $100K from my reading of the paper. So most uses of SHA1 are protecting documents of far lower value, and would not be likely attack targets (today).

<comment><USER52> There are many areas of security where you can genuinely get by with obfuscation, hoping the attacker looks elsewhere, or general security-through- obscurity.

You can't in crypto. When the entire system relies on an axiom being true, you need to make sure it's true. The attacks are only going to get better. The attacks are going to come from the future. The embedded systems will not be replaced in time.

</comment></comment><comment><USER53> _> Nine quintillion computations; 6,500 years of CPU; 110 years of GPU_

Is there a rough calculation in terms of today's $$$ cost to implement the attack?

<comment><USER54> They provide an estimate in their paper:

> The monetary cost of computing the second block of the

> attack by renting Amazon instances can be estimated from

> these various data. Using a p2.16xlarge instance,

> featuring 16 K80 GPUs and nominally costing

> US$ 14.4 per hour would cost US$ 560 K for the

> necessary 71 device years. It would be more economical

> for a patient attacker to wait for low "spot prices" of

> the smaller g2.8xlarge instances, which feature four K520

> GPUs, roughly equivalent to a K40 or a GTX 970. Assuming

> thusly an effort of 100 device years, and a typical spot

> price of US$ 0.5 per hour, the overall cost would be of

> US$ 110 K.

<comment><USER55> Eh, at that point you may as well buy the servers yourself and let them run on-premises. Even with power, etc. that cost could easily come down 50% or more. Once you own the servers, additional tasks just cost power.

<comment><USER56> In addition, as any bitcoin miner knows, AMD GPUs are actually far more efficient at calculating hashes.

</comment></comment></comment></comment><comment><USER57> Does git have any path away from SHA1?

I know the attack isn't practical today, but the writing is on the wall.

<comment><USER58> The writing has been on the wall for a long time, but Linus has been dead against it.

> And we should all digitally sign every single object too, and we should use > 4096-bit PGP keys and unguessable passphrases that are at least 20 words in > length. And we should then build a bunker 5 miles underground, encased in > lead, so that somebody cannot flip a few bits with a ray-gun, and make us > believe that the sha1's match when they don't. Oh, and we need to all wear > aluminum propeller beanies to make sure that they don't use that ray-gun to > make us do the modification _ourselves_.

He says it's not a security issue, so there are no "attacks" to protect against.

> the point is the SHA-1, as far as Git is concerned, isn't even a security > feature. It's purely a consistency check. The security parts are elsewhere, > so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for > cryptographically secure stuff, they think that, OK, it's a huge security > feature. It has nothing at all to do with security, it's just the best hash > you can get.

I don't know how correct that is.

<comment><USER59> At least in the current discussion, Linus says that eventually moving away from SHA1 in Git is a "no brainer," but that this announcement isn't a "sky is falling" moment. (e.g. [https://public- inbox.org/git/CA+55aFz98r7NC_3BW_1HU9-0C-HcrF...](https://public- email@example.com/))

<comment><USER58> Huh. And I've already got this 4-mile deep bunker hole...

</comment></comment></comment></comment><comment><USER60> How am I going to explain this to my wife?

Actually a serious question. How do we communicate something like this to the general public?

<comment><USER17> You don't really need to talk to anybody about this except people who torrent both illegal and legal torrents.

Torrent poisoning is the most ripe for exploitation and the one with the highest return for a malicious attacker.

So when you talk to someone who torrents, just tell them that the way the torrents verify a file is the correct one is no longer secure, and they have to keep an eye out for the next software update. And if anyone is paranoid, then stop downloading new torrent files, although there is no problem with seeding.

Now that I think about it, I think it is crucial for everyone to keep seeding as much as they can, because it reduces the probability of a bad torrent chunk from spreading as much across the network.

EDIT: Here's a good article that isn't very technical

[https://www.wired.com/2017/02/common-cryptographic-tool- turn...](https://www.wired.com/2017/02/common-cryptographic-tool-turns- majorly-insecure/)

<comment><USER61> wont an easy fix be to just hash it again with sha256? Sure that will take time to bake it into software, but wont they just be able to put a text label next to the description and say "sha256: abc...123" ?

<comment><USER17> Yes, but I doubt most would follow through.

</comment></comment></comment></comment><comment><USER62> > _We then leveraged Google's technical expertise and cloud infrastructure to > compute the collision which is one of the largest computations ever > completed._

And this, my friends, is why the big players (google, Amazon, etc) will win at the cloud offering game. When the instances are not purchased they can be used extensively internally.

</comment><comment><USER36> What's the impact to something like git that makes extensive use of SHA-1?

In their example they've created two PDFs with the same SHA-1. Could I replace the blob in a git repo with the "bad" version of a file if it matches the SHA-1?

<comment><USER63> This is not a pre-image attack, so you can't create a file that matches an existing SHA1. It's a collision attack, so you can create two files whose SHA1 is the same.

So what I could potentially do (given a multi-million dollar budget) is create from scratch two git repositories with different content, whose HEAD is the same. This would allow me to serve different repositories to different users.

What is currently still not feasible is to create a custom git repository whose HEAD matches that of the Linux kernel.

See also: [http://crypto.stackexchange.com/questions/1173/what-are- prei...](http://crypto.stackexchange.com/questions/1173/what-are-preimage- resistance-and-collision-resistance-and-how-can-the-lack-ther)

<comment><USER64> > _What is currently still not feasible is to create a custom git repository > whose HEAD matches that of the Linux kernel._

Hang on, that doesn't matter though, does it?

I was under the impression that git's SHAs were to be treated as repo-wise unique; not universally. There must non-adversarial 'collisions' across repositories already, surely?

I thought this attack potentially allows creating two commits in the same repo with the same hash - although it may only be possible for these to be root commits.

<comment><USER65> I don't think there's ever been an example of two different pieces of content hashing to the same SHA-1 before. An infinite number of such examples obviously must exist but they're incredibly improbably to encounter by accident.

<comment><USER64> Yep, sorry, it was far too early in the day for me to appreciate the magnitude of 2^{160}.

If I could downvote myself...

</comment></comment></comment></comment></comment><comment><USER66> The paper is available at [https://marc- stevens.nl/research/papers/SBKAM17-SHAttered.pd...](https://marc- stevens.nl/research/papers/SBKAM17-SHAttered.pdf)

</comment><comment><USER67> So, since Git uses SHA-1, does this mean we're going to see a new major version number of Git that uses SHA-2 or SHA-3 in a few years?

I don't expect one overnight. For one, as noted, this is a collision attack, one which took a large scale of power to achieve. In light of that, I don't think the integrity of git repos is in immediate danger. So I don't think it'd be an immediate concern of the the Git devs.

Secondly, wouldn't moving to SHA-2 or SHA-3 be a compatibility-breaking change? I'd think that would be painful to deal with, especially the larger the code base, or the more activity it sees. Linux itself would be a worst- case scenario in that regard. But, it can be pulled off for Linux, then I'd think any other code base should be achievable.

<comment><USER59> You can check out the git developer mailing list discussion here: [https://public- inbox.org/git/20170223164306.spg2avxzukkggrpb...](https://public- email@example.com/)

My rough summary: given there is no known second-preimage attack on SHA1, this is not an immediate danger to Git security because of the way Git works. The Git developers do want to move to a non-SHA1 hash at some point in the future.

Linus, from thread:

"I think that's a no-brainer, and we do want to have a path to eventually move towards SHA3-256 or whatever.

But I'm very definitely arguing that the current attack doesn't actually sound like it really even _matters_, because it should be so easy to mitigate against."

</comment></comment><comment><USER68> About tor: if an attacker produces a public key that collides with the SHA-1 hash of someone else's hidden service, then he would still need to generate the corresponding RSA-1024 private key, which is infeasible as of today.

Is this correct?

<comment><USER69> The method presented works only with data formats where you can add section of 'calculated junk' into the data.

Public key can't contain junk and work, so I don't see how this method would work.

</comment></comment><comment><USER70> " Today, 10 years after of SHA-1 was first introduced, we are announcing the first practical technique for generating a collision."

Huh? It's been around a lot longer than 10 years.

<comment><USER71> SSL 3.0 uses it, and that was released in 1996, and sha-1 was released in 1995 as an improvment over md5 and sha-0. This means it is 22 years old.

</comment></comment><comment><USER72> It's interesting to note that when the first MD5 collisions were discovered a bit over a decade ago, they were computed _by hand calculation_. Next came the collision generators like HashClash/fastcoll (remember these?) which could generate colliding MD5 blocks within a few _seconds_ on hardware of the time. I wonder how long it will be before the same can be done for SHA-1, because it seems here that they "simply" spent a large amount of computing power to generate the collision, but I'm hopeful that will be reduced very soon.

As for what I think in general about it: I'm not concerned, worried, or even scared about the effects. If anything, inelegance of brute-force aside, I think there's something very _beautiful_ and awe-inspiring in this discovery, like solving a puzzle or maths conjecture that has remained unsolved for many years.

I remember when I first heard about MD5 and hash functions in general, and thinking "it's completely deterministic. The operations don't look like they would be irreversible. There's just so many of them. It's only a matter of time before someone figures it out." Then, years later, it happened. It's an interesting feeling, especially since I used to crack softwares' registration key schemes which often resembled hash functions, and "reversing" the algorithms (basically a preimage attack) was simply a matter of time and careful thought.

There's still no practical preimage for MD5, but given enough time and interest... although I will vaguely guess that finding SHA-256 collisions probably has a higher priority to those interested.

</comment><comment><USER73> Maybe just writing 2^63 would have been easier to interpret than that huge number in the context of cryptography. (Unless you assume this targets a non- technical audience, which I doubt.)

Pretty impressive, though. And worrying, because if Google can do it, you know that state-level actors have been probably doing it for some time now (if only by throwing even more computing power at the problem).

</comment><comment><USER74> Seeing how they ridicule MD5, I think they should have spent a bit more time on the proof PDFs, and have their MD5 digests collide also.

<comment><USER52> No, that's irrelevant. You don't hold off showing the first SHA-1 collision to have it have MD5 collisions as well.

I don't think anyone in the field is surprised that the MD5 signatures are different for this file.

</comment></comment><comment><USER75> > _" Today, 10 years after of SHA-1 was first introduced, ..."_

That part from the original article seems to be missing something?

<comment><USER76> It must be supposed to say 10 years after first known collision of SHA-1 or something.

</comment></comment><comment><USER77> > How did you leverage the PDF format for this attack?

> A picture is worth a thousand words, so here it is.

> > [http://shattered.io/static/pdf_format.png](http://shattered.io/static/pdf_format.png)

This picture is meaningless to me. Can someone explain what's going on?

<comment><USER78> One can insert arbitrary data into JPGs. Given that, the researchers embedded a JPG in a PDF, and manipulated the arbitrary data until it resulted in a collision.

<comment><USER77> Sure, but you don't end up with two images that differ only in background of top half by accident...

</comment></comment></comment><comment><USER79> It's still quite impractical, m sure with some quantum computer or a custom ASIC built by those "super nerds" at the NSA its possible but but for you general adversary aka "hackers" (skiddies IMHO) it will be infeasible.

What this means is for all of you [developers], is to start new projects without SHA1 and plan on migrating old ones (if it's totally necessary, normally don't unless you use SHA1 for passwords).

A Great resource for those who still don't know how or what hash to use, is paragonie: [https://paragonie.com/blog/2016/02/how-safely-store- password...](https://paragonie.com/blog/2016/02/how-safely-store-password- in-2016)

</comment><comment><USER80> Related: someone claimed a 2.48 BTC (~2800 USD) bounty by using this SHA1 collision data: [https://news.ycombinator.com/item?id=13714987](https://news.ycombinator.com/item?id=13714987)

</comment><comment><USER17> Here's a good blog about how SHA-1 works:

[http://www.metamorphosite.com/one-way-hash-encryption- sha1-d...](http://www.metamorphosite.com/one-way-hash-encryption-sha1-d..).

The biggest risk I see with this is how torrents are affected:

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

There's also a problem with git, but I don't see it being that as susceptible as torrents:

[http://stackoverflow.com/a/34599081/6448137](http://stackoverflow.com/a/34599081/6448137)

<comment><USER23> What about git?

This makes it technically possible to get a backdoored linux repo with the same commit hash.

EDIT: this is wrong, it's not a second pre-image attack only a collision attack. That is, you can create 2 git repositories with the same commit hash, but not a git repo that matches an already existing repo. In other words, you can create 2 things with the same hash, but can't control what that hash actually is.

You might be able to fashion 2 commits to the linux repo with the same hash but a different modification though.

<comment><USER81> EDIT: My original comment was wrong. Git commit signing apparently only signs the commit hash itself, so it's only as trustworthy as the integrity of the hash. However, see also other comments which point out that this isn't a pre- image attack; you can't find a collision _for_ a given thing (in this case, the linux kernel); rather, you can generate from scratch two pieces of data which happen to collide. Still, this is worrying.

ORIGINALLY (INCORRECT): Git commit hashes were at least never intended as a form of authentication. That's why git has commit signing. That said, they list GPG signatures as one of the things affected by SHA1 brokenness, so maybe even that's not enough? I don't know enough about how git commit signing or GPG works to tell.

<comment><USER69> >git has commit signing

What the commit actually signs? Is it the sha1 hash?

<comment><USER82> The commit object is signed; which contains a signature to both the tree _and_ the parent. I don't see it as feasible to do a collision on both at once with the method outlined here, but maybe I'm missing something.

Tagging on the other hand is at risk, as it's just the hash that's signed.

Edit: You can check what is actually signed with `git cat-file -p $obj` where $obj is a commit or tag id.

<comment><USER25> You could also find a preimage for any tree or blob object referenced by that commit. And in large projects, you have a lot to choose from.

(As has been stated, I know this isn't a second preimage attack.)

Edit: See my answers in this thread: [https://lists.gnu.org/archive/html/bug- guix/2016-06/msg00009...](https://lists.gnu.org/archive/html/bug- guix/2016-06/msg00009.html)

</comment></comment></comment></comment></comment></comment><comment><USER83> Anyone have back of the envelope calculations for the cost of the CPU and GPU time?

<comment><USER84> On the shattered webpage:

This attack required over 9,223,372,036,854,775,808 SHA1 computations. This took the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations.

<comment><USER85> So... you are saying I couldn't do this on my Macbook's Core i7?

<comment><USER86> If you're very careful with your machine maybe you can make it last 6500 years, but I think that is way outside the expected lifetime of a mobile CPU under full load.

</comment></comment></comment></comment><comment><USER87> So good timing to have just started working on a sha3 version of git I guess...

<comment><USER88> Funny, just yesterday I thought about what would be necessary to change and deploy this. Apparently the SHA1 hash wasn't designed as a security feature, but I would not be surprised if it is being abused as one today.

<comment><USER89> It's not used as a security feature in Git (though SHA-1 is designed as a cryptographically secure hash) but Git commit singing does use SHA-1 b/c GPG.

<comment><USER88> It's not supposed to be used as a security feature, but I think some tools use it as such. Dependency management tools that reference by SHA-1 hash come to mind. Of course they should have used other primitives all along, but we know how it is..

</comment></comment></comment></comment><comment><USER90> How do you actually create a collision? The paper is beyond my level of comprehensions. Are we going to see someone writing up an open source tool to allow one to generate another file with the same hash?

</comment><comment><USER91> It should also be noted that their examples files also have the same file size, in this case 422435 bits, after creating the collision - which I find fascinating!

</comment><comment><USER92> It's kind of odd that over 9 months ago it was known that Microsoft would stop honoring SHA-1 certificates starting from 1 week ago. Anyone know if this is just a pure coincidence? See [https://blogs.windows.com/msedgedev/2016/04/29/sha1-deprecat...](https://blogs.windows.com/msedgedev/2016/04/29/sha1-deprecation- roadmap/)

<comment><USER93> Not following on MS?

</comment></comment><comment><USER94> It appears they are using a 2^63 hash operation attack that has been well known for nearly a decade. (Brute force of SHA-1 is 2^69.)

I wonder why they did not use the 2^52 operation attack that Schneier noted in 2009?

[https://www.schneier.com/blog/archives/2009/06/ever_better_c...](https://www.schneier.com/blog/archives/2009/06/ever_better_cry.html)

</comment><comment><USER95> I got a chuckle out of the binary diff. :)

[http://i.imgur.com/OmFHELl.png](http://i.imgur.com/OmFHELl.png)

<comment><USER96> Why?

[Edit] Just saw it. This is why I shouldn't read HN on my phone.

<comment><USER97> i don't get it

<comment><USER96> If you look at the textual representation of the hex sequences, you can find the string "SHA-1 is dead!!!!!".

</comment></comment></comment></comment><comment><USER98> Forgive my ignorance, but it seems a solution to collision worries is to just use two hashing algorithms instead of one. We have two factor authentication for logins, why not the equivalent for hashed things?

Give me the sha1 and md5, rather than one or the other. Am I wrong in thinking even if one or both are broken individually, having both broken for the same data is an order of magnitude more complex?

<comment><USER33> You're effectively creating a new hashing algorithm, which is twice as long and twice as slow, and is built using constructs known to be weak.

<comment><USER98> Thanks, that makes sense.

</comment></comment></comment><comment><USER42> Anyone good enough in AWS pricing can reproduce the $100k pricing for one collision ? Using EC2 g2.xlarge instances I'm more at $2.8M.

<comment><USER99> This would still be just an average, right? Isn't it 0$ to $2.8M depending on luck?

<comment><USER42> I don't think that's how averages work. But it's true that relying on the birthday paradox, you can reduce the average. I was just trying to compute the "cloud" cost of 110 GPUs for 1 year (or the equivalent for a day, assuming this is embarrassingly parallel).

</comment></comment></comment><comment><USER100> I wish there were sample documents, but if one had two computed hashes would this mitigate this SHA1-shattered flaw ? e.g. good_doc.pdf sha1=da39a3ee5e6b4b0d3255bfef95601890afd80709, md5=d41d8cd98f00b204e9800998ecf8427e ? With the sample project I'm looking at (GraphicsMagick) on Sourceforge for example, it provides both SHA-1 and MD5 hashes...

<comment><USER101> Why would you ever want to add a second broken hash like MD5 instead of just using a single secure function like SHA2, SHA3, or BLAKE2?

<comment><USER100> Only for the case like I mentioned (SourceForge example above) of verifying payloads that only ship with those two broken hashes. Not advocating for publishing new work like this.

</comment></comment></comment><comment><USER102> What's funny is Google still promotes SHA-1 in some of their APIs: [https://developers.google.com/admin- sdk/directory/v1/guides/...](https://developers.google.com/admin- sdk/directory/v1/guides/manage-users)

</comment><comment><USER103> I wonder if there are any 2 single commits on Github from different repositories that have the same SHA1 hash.

<comment><USER104> If there was, then _that_ would have been the first SHA-1 collision, right? ;P

<comment><USER103> Yes, but is anyone looking?

</comment></comment></comment><comment><USER105> Is a 30 day disclosure period really enough for something like this? It's obviously not possible to 'fix' big systems that rely on SHA-1 such as git or github in only 30 days. Hardware devices that use SHA-1 as a base for authenticating firmware updates?

<comment><USER106> SHA1 was shown to be flawed in 2005. That's more than 30 days ago.

<comment><USER107> Saying it was shown to be flawed is being nice. It was outright broken 12 years ago as it was shown that you could find collisions with far less complexity that a bruteforce attack.

What has happened is that someone created the code to actually carry out an attack, and showed that it will cost around $110K today.

</comment></comment></comment><comment><USER108> Can someone help me understand what the major distinction is between this accomplishment (SHAttered) and the same team's The SHAppening (2015)?

It looks like the did the same thing or something similar in 2^57.5 SHA1 calculations back then versus 2^63 SHA1 calculations this time.

<comment><USER109> SHAppening was a freestart collision, this is a "full" one. This stack overflow answer looks like a good description of freestart collisions: [https://crypto.stackexchange.com/questions/29695/what-is- a-f...](https://crypto.stackexchange.com/questions/29695/what-is-a-freestart- collision)

My attempt at TL;DR: SHA-1 works on blocks, and each block is processed and it's data "mixed" with a previous intermediate result based on the previous blocks (Merkle-Damgård construction). A freestart collision only shows blocks and values for the intermediate results which lead to a collision. For a full collision you still have to figure out what sequence of blocks gets the intermediate results to the necessary values.

<comment><USER108> Ah, cool. I didn't notice the distinction between freestart and full. Thanks for that link; it was very helpful.

</comment></comment></comment><comment><USER110> SHA-1 isn't broken until someone makes a multi step quine that hashes to the same value at every stage!

BTW quine relay is impressive: [https://github.com/mame/quine- relay](https://github.com/mame/quine-relay)

</comment><comment><USER111> This is one of the reasons it is important to have multiple hash algorithms in use. Even when a collision can be triggered in two systems, it becomes markedly harder to trigger a simultaneous collision in other systems at that same point (payload).

</comment><comment><USER112> > "10 years after of SHA-1 was first introduced"

wasn't SHA-1 introduced in the 90's?

<comment><USER113> Git was released in 2005, 12 years ago, and it's based around SHA-1. They've done a massive miscalculation there.

<comment><USER114> OTOH, 12 years of reliability from a checksum in the age of Moore's law and quantum computers is pretty good, frankly.

I don't think they ever expected sha-1 to survive forever.

<comment><USER113> Sure.

In fact I intended to refer to the 10 year figure as massive miscalculation here.

Even the simplest messages have ambiguity.

</comment></comment></comment></comment><comment><USER115> Would providing multiple SHA-1's from both the whole and N subsections (or defined regions) of the byte stream make this impractical... or at this point is the cost just going to drop and make this not relevant?

Like a NURBS based sudoku multi-hash...

</comment><comment><USER116> [https://security.googleblog.com](https://security.googleblog.com) : "This website uses a weak security configuration (SHA-1 signatures), so your connection may not be private."

<comment><AUTHOR> I get a SHA256 certificate for that site. What user agent are you using? Is there some kind of middlebox on your network, or do you use AV software that intercepts TLS connections?

<comment><USER116> Fair enough, I was using Chrome "Version 50.0.2661.102 (64-bit)" on Linux Mint. I have updated it to 56.0.2924.87, now I'm getting a full error page "Your connection is not private" NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM. I need to search for this issue now.

No I'm not using anything that intercepts TLS connections.

EDIT: It's fixed now, `sudo apt-get install libnss3-1d`.

[http://askubuntu.com/questions/880695/neterr-cert-weak- signa...](http://askubuntu.com/questions/880695/neterr-cert-weak-signature- algorithm-error-for-google-chrome-stable-version)

</comment></comment></comment><comment><USER117> What's the over/under on how long ago the NSA accomplished this?

</comment><comment><USER118> If you trust a signer, does this attack do anything to invalidate their SHA-1-based signatures? Or is the scenario strictly an attacker generating both versions of the message?

<comment><USER119> As I understand it the attacker would have to generate both versions of the message. If an attacker could generate a second message with a hash that matches that of an existing message from a third party, that would be a second-preimage attack, not merely a collision attack.

Even MD5 is still considered to be second-preimage resistant: [http://crypto.stackexchange.com/q/3441/21238](http://crypto.stackexchange.com/q/3441/21238)

</comment></comment><comment><USER120> The changes will be massive:

[https://github.com/search?utf8=%E2%9C%93&q=sha-1](https://github.com/search?utf8=%E2%9C%93&q=sha-1)

</comment><comment><USER121> 10 million GPUs is not insane when you have a billion dollar security cracking infrastructure budget. Especially when you compare it to the rest of the cyber warfare budget.

</comment><comment><USER122> Is it coincidental that this GPUs on Compute Enginge were announced recently? This seems like a nice burn-in test and it being completed should free up ressources.

</comment><comment><USER123> > Google has advocated the deprecation of SHA-1 for many years, particularly > when it comes to signing TLS certificates.

Why? Was it in anticipation of this attack specifically?

</comment><comment><USER124> Is Mercurial impacted?

<comment><USER125> Yes, as it uses a similar hashing scheme as git. [https://www.mercurial- scm.org/wiki/FAQ#FAQ.2FTechnicalDetail...](https://www.mercurial- scm.org/wiki/FAQ#FAQ.2FTechnicalDetails.What_about_hash_collisions.3F_What_about_weaknesses_in_SHA1.3F)

That said the file format was switched pretty early on (2006 I think, less than a year after initial release) to reserve space for 32 bytes instead of 20 for the hash, thus allowing hash migration more easily (sha1 is 20 bytes, sha2 which at the time was the obvious replacement was 32 bytes). [https://www.mercurial-scm.org/wiki/RevlogNG](https://www.mercurial- scm.org/wiki/RevlogNG)

<comment><USER126> Except all exchanges between mercurial client and server happen with changegroups and changegroups are still limited to 20 bytes for the hash.

</comment></comment></comment><comment><USER127> I don't know too much about hashing/encryption, but if you salt the sha-1 will this still be able to find a collision?

</comment><comment><USER128> So is this why Google asked me to type in my password this afternoon? Cause I was kinda cautious about that, but still did it...

</comment><comment><USER129> So from a security standpoint if my hash was a sha-1 concatenated to an MD5, how long would it be before they found a collision?

<comment><USER130> I believe there is a way to do it so that the MD5 collision would only be 2^64. This is also how MD5 collisions can be created without any special techniques, meaning that MD5 was always only barely more secure than 56-bit DES for example.

</comment></comment><comment><USER131> Is there any merit to using two hashing algorithms simultaneously particularly if the algorithms are very different in nature?

</comment><comment><USER132> As I consumer how do I identify sites which are vulnerable? What should I do to protect my data?

<comment><AUTHOR> Recent versions of Chrome will show a warning if you try to browse to a site that uses a SHA-1 certificate. Mozilla is doing the same thing as of Firefox 51, but they're enabling this gradually to measure impact. Microsoft has an update ready to disable SHA-1 support in their browsers - I think it was delayed a few days ago due to some issues (not sure if they were related to disabling SHA-1).

You can use [1] to test how your browser behaves.

Technically, the sites cannot be said to be vulnerable because of their SHA-1 usage. Rather, continuing issuance of SHA-1 certificates by publicly-trusted CAs increases the risk that someone obtains a certificate that collides with a certificate for a different domain or for a certificate that could be used to sign other certificates for sites the attacker does not own. [2] does a good job of explaining this. The mitigation for this is to use a browser that disables (or warns about) SHA-1 certificates. Publicly-trusted CAs are also not supposed to continue issuing these certificates, but there have been quite a number of cases where they did so anyway - most notably WoSign.

Of course, a site might use SHA-1 for other things behind the scenes. There's really no way to detect that in general.

[1]: [https://sha1-2017.badssl.com/](https://sha1-2017.badssl.com/)

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

<comment><USER77> > [https://sha1-2017.badssl.com/](https://sha1-2017.badssl.com/)

This certificate has expired, so it's not that useful for testing.

</comment></comment></comment><comment><USER133> "as google, we spent two years to research a way of generating sha-1 collisions and made quintillions of computations to generate an example" <\- not very convincing or practical. It's like those japanese animes where the nerdy kid boasts about having computed your every move.

</comment><comment><USER134> "But MD5 is still okay right?" -Laravel Developer

<comment><USER135> This comment does not really add much of anything. Besides that, Laravel uses Bcrypt for hashing. Not sure where Laravel developers use MD5.

</comment></comment><comment><USER136> > _In practice, collisions should never occur for secure hash functions._

That is mathematically impossible when reducing an N bit string to an M bit string, where N > M.

All hashes have collisions; it's just how hard are they to find.

<comment><USER77> They said "in practice" for a reason.

</comment></comment><comment><USER137> It's telling/ironic that the google security blog will not display the text without javascript enabled.

</comment><comment><USER138> but ... but .... half of the web is no longer secure? ... :D

</comment><comment><USER139> > If you use Chrome, you will be automatically protected from insecure TLS/SSL > certificates, and Firefox has this feature planned for early 2017.

No need to wait. The option to reject SHA-1 certificates on Firefox is `security.pki.sha1_enforcement_level` with value `1`.

[https://blog.mozilla.org/security/2016/01/06/man-in-the- midd...](https://blog.mozilla.org/security/2016/01/06/man-in-the-middle- interfering-with-increased-security/)

Other configs worth doing:

`security.ssl.treat_unsafe_negotiation_as_broken` to `true` and `security.ssl.require_safe_negotiation` to `true` also. Refusing insecure algorithms (`security.ssl3.<alg>`) might also be smart.

<comment><USER140> Excellent.

More generally, there is this fantastic repo on github that lists a bunch of such things that can be tweaked in about:config (mostly from a security/privacy standpoint): [https://github.com/pyllyukko/user.js](https://github.com/pyllyukko/user.js)

</comment></comment><comment><USER141> Never forget: when Facebook, Twitter, and Cloudflare tried to slow-down SHA-1 deprecation:

[https://www.facebook.com/notes/alex-stamos/the- sha-1-sunset/...](https://www.facebook.com/notes/alex-stamos/the- sha-1-sunset/10153782990367929)

[https://blog.twitter.com/2015/sunsetting- sha-1](https://blog.twitter.com/2015/sunsetting-sha-1)

[https://blog.cloudflare.com/sha-1-deprecation-no-browser- lef...](https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/)

I think Microsoft tried to do it too early on, but eventually agreed to a more aggressive timeline.

<comment><AUTHOR> Worth noting that Facebook stopped offering SHA-1 back in November[1]. Cloudflare still offers SHA-1 for paying customers (via a root certificate pulled from trust stores, i.e. which are only supported on outdated devices/browsers). Not sure about Twitter.

[1]: [https://www.facebook.com/notes/protect-the-graph/retiring- sh...](https://www.facebook.com/notes/protect-the-graph/retiring- sha-1-certificates/1814716098768533)

</comment></comment><comment><USER142> > Hash functions compress large amounts of data into a small message digest.

My understanding of crypto concepts is very limited, but isn't this inaccurate? Hash functions do not compress anything.

They have an image too which says "<big number> SHA-1 compressions performed".

Seems weird to see basic mistakes in a research disclosure.

<comment><USER143> [https://en.m.wikipedia.org/wiki/One- way_compression_function](https://en.m.wikipedia.org/wiki/One- way_compression_function)

Cryptographic compression is not related to data compression.

</comment></comment><comment><USER144> Now I really wonder what will happen to Git we all know and love.

<comment><USER145> Nothing: the risk of a fucked up rebase is still much higher than a hash collision.

<comment><USER144> If we think that intentional collision is not a threat vector, while, as life shows, it is: [https://bugs.webkit.org/show_bug.cgi?id=168774#c23](https://bugs.webkit.org/show_bug.cgi?id=168774#c23)

</comment></comment></comment><comment><USER130> identical prefix, not chosen prefix. I was more interested in an SHA-1 collision ASIC.</comment>


Apple Is Worth $1Tn. Two Decades Ago, It Was Almost Bankrupt - <AUTHOR> https://www.nytimes.com/2018/08/02/technology/apple-stock-1-trillion-market-cap.html <comment><USER2> Previously:

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

</comment><comment><USER3> this title...that's the weirdest way I've ever seen anyone write one trillion.. one billion thousand dollars?

<comment><USER4> They changed it now but I use the RSS feed and I noticed the same thing. It was: $1B,000 which I assume was trying to be a clever way of saying "add 3 zeros to a billion.

</comment></comment><comment><USER5> I think that nobody questions that the main factor for this meteoric rise in valuation was Steve Jobs it just proves that the entrepreneur and is vision are the main factors on the growth of companies.</comment>


Ask HN: Is Using DuckDuckGo and Google Chrome Useless? - <AUTHOR> I'm curious if there are people that use both and why. Does anyone have expert knowledge on how much  data the Chrome Browser collects during usage? <comment><USER2> If you prefer to use a Chromium-based browser, ungoogled-chromium is a frequently recommended option:

[https://github.com/Eloston/ungoogled- chromium](https://github.com/Eloston/ungoogled-chromium)

DuckDuckGo is the default search engine, and most of the Google-related tracking is disabled or removed. You can see the details in the repository's README.md.

This works well for privacy-conscious users who, for some reason, don't want to use Firefox. If you have no objection to Firefox, it would be in your best interest to use Firefox since it's backed by a non-profit dedicated to open web standards.

</comment><comment><USER3> I don't use duckduckgo, but there is a project that might have more info, it removes tracking data from chromium.

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

<comment><USER4> > Although SRWare has been claiming "Iron is free and OpenSource", this wasn't > true from at least version 6 on until mid 2015, as the links given by them > for the source code were hosted in RapidShare and blocked by the uploader. > SRWare Iron "is entirely closed source and has been since at least version > 6". According to Lifehacker, as of October 2014 SRWare Iron was "supposedly > open source but haven't released their source for years". In 2015, SRWare > resumed releasing what they claim is the source code for the browser, > although not stating on their page what version the source code is from.

yeah I think I'd rather run Chrome...

<comment><USER3> You don't need to run it to read the wikipedia page...

</comment></comment></comment><comment><USER5> Take a look at Iridium, which is chrome stripped from everything that hurts privacy

</comment><comment><USER6> You probably want to check out brave. Brave.com

I would struggle to find the references, but supposedly google keeps their teams separate, which is why using google analytics and google chrome don't talk to each other.

Either way DDG is a pretty solid search engine, useful as a second source if google aint working for you.

<comment><USER7> I would suggest either Firefox or Safari instead of Brave. Brave is an ad platform.

<comment><USER8> As a recent Brave convert, I was skeptical of Brave for the same reason.

I switched to it from Firefox (after switching months ago from Chrome) due to Firefox being slow, tabs repeatedly crashing, UX disharmony, and the recent cert addon debacle.

Brave's ad proposition makes sense: the internet is inundated with ads, which is unpleasant, but free websites do need to survive. So, make the ad landscape nicer on an opt in basis.

They take privacy seriously. I'd recommend it.</comment></comment></comment>


Monotonic Versioning Manifesto 1.0 - <AUTHOR> http://blog.appliedcompscilab.com/monotonic_versioning_manifesto/ <comment><USER2>
       1. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.

I know it's a derivative of Semantic Versioning, but this should probably be corrected.</comment>


Law Professor's Blog Post Sparks Controversy Over Why The Rich Don't Feel 'Rich' - <AUTHOR> http://www.huffingtonpost.com/2010/09/21/todd-henderson-rich_n_732813.html

<comment></comment>


Am I the only one seeing the '90s retro theme, with the unicorns and sparkles? - <AUTHOR> https://meta.stackoverflow.com/questions/382047/am-i-the-only-one-seeing-the-90s-retro-theme-with-the-unicorns-and-sparkles <comment><USER2> Greatly appreciate the popup that lets you disable the joke interface. Much appreciated.

</comment><comment><USER3> Why are all the answers for this question not "yes". What is wrong with everyone.

<comment><USER4> I'm reminded of this Reddit post [0]. What a win for the community

[0] [https://www.reddit.com/r/AskReddit/comments/cq1q2/help_reddi...](https://www.reddit.com/r/AskReddit/comments/cq1q2/help_reddit_turned_spanish_and_i_cannot_undo_it/)

<comment><USER3> Oh my that is such a thing of beauty. Thank you. <3

</comment></comment></comment><comment><USER5> And so it begins.

<comment><USER6> This is where globalisation really hurts. You used to have to hide 24 hours under a rock to avoid it, but with different time zones and all that jazz on the internet, it starts early and ends late.

<comment><USER7> Too bad it's impossible to figure out the time zone from the browser or anything.

<comment><USER8> Well, you can, but you can't trust the time. They could have the clock set a few months back to avoid silly certificate expiration errors. Though I suppose Summer Fools Day is fine too.

</comment></comment></comment></comment><comment><USER9> Ugh. A good joke would be to have no crappy joke one year, and then tell everyone that they should look out for a good one next year. Repeat.

</comment><comment><USER10> Very similar to slashdot's pink unicorn theme 'prank' years ago.

This is the lamest holiday. I hope I live to see it retired.

<comment><USER11> HN users mostly flag April 1 gags. Moderators penalize them as well.

The community is divided, but I think most people feel they stopped being interesting years ago.

</comment></comment><comment> village-idiot One of the more obnoxious "pranks" I've seen in a while, especially since it turns itself back on on every single visit.

</comment><comment><AUTHOR> Related: [http://www.wonder-tonic.com/geocitiesizer/](http://www.wonder- tonic.com/geocitiesizer/)

</comment><comment><USER12> Head ache inducing.

</comment><comment><USER13> This is epic haha

</comment><comment><USER14> I despise globocorporate April Fools pranks as much as anyone but the aesthetic here is really well done.

<comment><USER15> Stackoverflow is hardly "globocorporate".

<comment><USER16> It pretty much controls all programmers who read English.

</comment></comment></comment><comment><USER17> The mildly ironic fact is that those effects are created using modern CSS/JS resources and not just <table>s in true 90s way

<comment><USER14> That's a valid critique of small prank sites like this [https://www.marvel.com/captainmarvel/](https://www.marvel.com/captainmarvel/), but in this case StackOverflow's normal functionality still has to work

</comment></comment><comment><USER18> This is so good, and really takes me back to that time.

For some context, I've recently been particularly interested in listening to CDs (I even just bought a CD-ROM burner today, wtf...), learning programming languages from books, and trying not to stream things. So, maybe I'm stuck in the past, but I'm super grateful for this particular joke. It gives me a really warm feeling in my heart :)

Thanks to those developers who put this together, and I hope that we can all take the hint and slow the f* down, study the capabilities of the technologies we've built, and figure out how to save the planet (and the human civilizations it's grown) from itself.</comment>


This pic of rms always makes me smile - <AUTHOR> http://www.stallman.org/rms.jpg

<comment><USER2> Whenever I see a picture of RMS, I always think about the smell. From the stories I've heard, it's probably not very pleasant.

<comment><USER3> Last time I met him (though, it was a couple of years ago), he smelled like any other ordinary human being.

A random suit after 8 hours of office work is far worse.</comment></comment>


I have vulvodynia – but countless gynaecologists dismissed my agony (2017) - <AUTHOR> https://www.theguardian.com/commentisfree/2017/mar/28/gynaecologists-pain-women-vulvodynia-misdiagnoses <comment><USER2> It's a mistake to consider this a feminist issue.

Men with chronic pain will show up at a doctor and see the doctor scribble "N. A. D." (No Apparent Distress) even though they are going to the doc because they are distressed.

People with back pain, neck pain, etc. lose many years of their life to lacking, ineffectual, or harmful (surgery and opioid) treatments. That's why most men suffer through it and sometimes the first that most of the people who "know them" find out about it is after the suicide.

That is, women are not oppressed relative to men, they just expect more. (Maybe they should and men should too...)

<comment><USER3> There really are too many "I know you better than you do" doctors out there. There should be a consumer panel that rates doctors according to their efforts towards a successful treatment.

<comment><USER2> It is not just that, it is also that there are not reproducible methods for helping people with chronic pain.

The lady who wrote the article had a lot of resentment about the suggestion that her problems were at least partially psychological and insisted that they were completely physical.

You will hear that from every fibro, and it is real that there is something not right about their body, but also there is something not right in their head, they are clearly depressed, have given up on life, etc. Chronic pain is always both physical and mental.

For me chronic pain has been associated with trouble at work. I had a time when I was unemployed and in agony and I got a job and felt better right away. When I have been in places where the story doesn't make sense, I feel it in my back and shoulders.

So far as consumer panels, unfortunately health care practitioners would get voted up for being easy to prescribe controlled substances, not making patients confront people whose race they don't like, etc...</comment></comment></comment>


Bay Area Living in Shipping Containers - <AUTHOR> http://www.bloomberg.com/news/articles/2015-07-30/wharton-grad-s-got-a-tiny-illegal-solution-to-bay-area-housing <comment><USER2> _In Los Altos, Brandon Williams crams 14 tenants into a four-bedroom, two- bathroom house -- where monthly rates for a bed start at $1,000. He leases the bungalow from a Chinese venture capitalist for about $6,800, which he can more than double when all the beds are occupied.

"This is scalable," said Williams, 28, a freelance electrical engineer. "I know a guy who has about 12 of these."_

What a scumbag.

<comment><USER3> I live in one of these in San Francisco, and honestly I love it. For $1700/mo I can live in a nice residential neighborhood with a <10 minute commute. There's a full kitchen and a very spacious common area with couches, tables, a TV, and plenty of power. I sleep in one of the eight bunks in the master bedroom, right next to a balcony with a beautiful view of the skyline. Most of us are interns and temp contractors, with an occasional "adult" passing through while looking for permanent housing. Honestly, it's a lot nicer than my University housing and not much more expensive.

Without it, I'd have to either live somewhere where I fear for my safety, add 1-2 hours of BART commute onto my workday (and lose easy access to SF restaurants/culture), or spend $2500-$4000 for a studio in a comparable neighborhood.

<comment><USER4> I'm not contradicting you, but $1700/mo for an incredibly overcrowded dorm room? Undergrad, doubles converted to triples were considered overcrowded. Wow. Maybe that's the norm in SF these days but it's not something I would have ever considered post-school.

<comment><USER3> The master bedroom is huge; a king-size bed would have taken less than 30% of the floor. There are two walk-in closets and a private bath.

Downstairs, there are 2 bedrooms that could have easily held 2 twin beds each, and another small room that could have taken 1 twin bed.

As a single-family home it would have comfortably slept 7. It's probably 2-3x larger than my childhood home and would have fetched $750,000+ in the suburban Midwest.

Convert all those twins to bunk beds (as my landlord did) and you've got 10 people across the downstairs bedrooms. Replace the king-size bed with 2 bunk beds, you've got 4 beds in the space where 1 was. 14 people sleeping in the same amount of floor space that 7 previously occupied. Now take the vast empty floor space in the master bedroom and add 2 bunk beds, and you're at the 18 that I live with.

It doesn't feel crowded. It has the same drawbacks that any room-sharing situation has - you're never alone, you have to hear people breathe and snore and shift around in bed, there's no possibility of having sex (you can sexile one person - not 7), you have to smell people's smells. But it's no worse than living in a double in college, summer camp, etc. I had no chance of bringing a girl home anyway, the sounds are drowned out by the city/wind when you've got a window open, and everyone is polite and sensitive to the fact that we're sharing space.

A portion of that price also goes to Airbnb, which gives me trust/reputation, escrow, precisely the dates of stay I wanted, and no monthslong Craigslist game as is usually necessary to sublet in SF.

<comment><USER4> Oh I understand it may be preferable to the alternatives. I just find paying that kind of money to effectively live in a hostel as a working professional to be pretty mind blowing. I'm glad I was never personally in that sort of situation.

</comment></comment></comment></comment></comment><comment><USER5> In crowded markets, the materials cost is rarely significant compared to the real estate it sits on - living in a tent is still prohibitively expensive if you have to lease the square footage it is pitched on. This article is more about breaking zoning laws to save money than it is about shipping containers vs traditional construction.

<comment><USER6> _> living in a tent is still prohibitively expensive if you have to lease the square footage it is pitched on_

The difference is tents aren't designed to be stackable. [https://www.google.com/search?q=shipping+container+stacks&tb...](https://www.google.com/search?q=shipping+container+stacks&tbm=isch)

But as below comments mention, generally steel intermodal containers make pretty poor livable areas for a variety of reasons. Lack of insulation, hard surfaces, contamination from previous contents, weight and difficulty in handling without heavy machinery, lack of local sourcability, etc. etc.

Your ideal use case is probably a port area with extremely high population density and an advanced economy (for heavy machinery) but an extremely high wealth disparity, in a reasonable climate. So, maybe SE Asian port cities? With a sacrificial layer of containers on the outside to heat-sink?

</comment></comment><comment><USER7> This stuff is straight out of "Snow Crash" by Neal Stephenson. What's next? Facebook powered Metaverse and bikers with sovereign status because they pack personal nuclear weapons?

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

<comment><USER8> I accept this future as long as rat things (robotic, nuclear powered creatures matching the form of a canine) become a thing.

"As part of Mr. Lee's good neighbor policy, all Rat Things are programmed never to break the sound barrier in a populated area. But Fido's in too much of a hurry to worry about the good neighbor policy."

<comment><USER9> Jack the barrier. Bring the noise.

</comment></comment></comment><comment><USER10> Have seen numerous shipping container housing projects over the years and none of them really took off. To make containers truly livable long term (combining multiple containers, decent finishes, buildout etc) it seems to cross a price threshold where a person who can afford to do it would likely build a traditional dwelling.

This is more about creative subdividing to me. Whether it's a tent or a shipping container.

<comment><USER11> In Ghana they are used extensively as shops/storefronts, but no one lives in shipping containers. Even in the most rural areas, people make houses literally brick by brick (buying 1-2 bricks at a time) instead of using shipping containers for housing. I think it's for the reason you suggest, and for the additional reason that I imagine living in a shipping container to be somewhat akin to living in a big metal dumpster.

<comment><USER12> Why would anyone buy bricks in such small numbers, instead of saving up? A wall with two extra bricks on it isn't more useful.

Is it just impossible to save money safely?

<comment><USER13> In this [1] excellent book, it is said that they do it as form of saving. Basically, they don't have bank accounts, and they know that if they don't buy those 1-2 bricks right away after they get paid, they'll spend the money on something else.

[1] [http://www.amazon.com/Poor-Economics-Radical-Rethinking- Pove...](http://www.amazon.com/Poor-Economics-Radical-Rethinking- Poverty/dp/1610390938/ref=sr_1_1?ie=UTF8&qid=1438279525&sr=8-1&keywords=poverty+economics)

<comment><USER11> This is a large part of the reason. Money that gets earned gets spent pretty quickly on one thing or another, and it would be next to impossible for a family to save up enough to buy all the materials to build a house in one go.

Another reason is that they don't have easy access to credit markets, so they can't just get a mortgage and move into a home and start paying it off.

One more part of the reason is that they usually build the homes themselves, and its rewarding to see the house go up brick by brick - visual progress is being made.

I'm not an expert, but these are my informed observations and learnings.

</comment></comment></comment></comment></comment><comment><USER14> It's a bit amusing to me that a concept originally envisioned to help provide housing for the destitute is now being pitched as tech worker housing in the bay area...

</comment><comment><USER15> "Cargotecture" is not uncommon in the Netherlands:

Shipping Container Houses, Amsterdam Noord

[http://greetingsfromholland.blogspot.nl/2010/08/shipping- con...](http://greetingsfromholland.blogspot.nl/2010/08/shipping-container- houses-amsterdam.html)

Keetwonen (Amsterdam student housing)

[http://www.tempohousing.com/projects/keetwonen.html](http://www.tempohousing.com/projects/keetwonen.html)

Amsterdam's Shipping Container Homes Are Lean And Green

[http://www.huffingtonpost.com/2012/06/08/amsterdam- shipping-...](http://www.huffingtonpost.com/2012/06/08/amsterdam-shipping- container-homes_n_1582216.html)

Shipping Container Architecture

[http://blog.designpublic.com/2008/10/27/shipping- container-a...](http://blog.designpublic.com/2008/10/27/shipping-container- architecture/)

The Dutch have a thing for recycled architecture. You can see the colorful student shipping container housing off in the distance from the bungee jumping platform at the top of the luxurious Faralda Crane Hotel at NDSM ship wharf, at around 10:00:

[https://www.youtube.com/watch?v=860OXQjf87w](https://www.youtube.com/watch?v=860OXQjf87w)

They even made the KamerMaker, a 3D house printer, in a shipping container:

[http://www.threefarm.com/http/threefarmtumblrcom/2014/3/18/t...](http://www.threefarm.com/http/threefarmtumblrcom/2014/3/18/the- first-3d-printed-house-is-under-construction)

</comment><comment><USER16> This is a terrible idea. The problem is not finding cheap building materials but optimizing land use.

I look around the bay area and I see a ton of single family homes. Where are the large multi-story apartment buildings?

<comment><USER17> Being beaten down by a multitude of NIMBY forces, powered by perverse incentives.

<comment><USER18> yeah, perverse incentives like preserving natural beauty and avoiding untenable population density

edit: but if you build larger living spaces in places that nobody wants to live, i'm happy with that

<comment><USER19> Building up is a perfect balance between preserving beauty and nature and price.

The reality is that the real blight on nature is the single family homes which are built on forests and farmland.

</comment></comment></comment></comment><comment><USER20> Honestly, I think these people are dicks: [http://kalw.org/post/how-tiny- shipping-container-community-c...](http://kalw.org/post/how-tiny-shipping- container-community-causing-big-fuss-oakland)

Not only is this an issue of residential codes. The other problem is that they're doing manufacturing in a residential neighborhood that's not zoned for manufacturing. And it's disturbing the neighbors in the area with noise and even sewage spillover.

<comment><USER21> They sound so ridiculously tone deaf like the idea of having people move into your neighbor and build houses from the ground up, unregulated, out of shipping containers shouldn't bother anyone in the slightest.

</comment></comment><comment><USER22> Problem with shipping containers is that they should be decontaminated and sanded down prior to living use - the contents get gassed, leak out dangerous stuff and old insulation materials may prove dangerous, same for the paint.

<comment><USER23> Good point. Also, I can't imagine it's safe to be running that camp stove in an enclosed space either.

<comment><USER24> It never is. That's why all camp stoves come with a warning not to cook in enclosed spaces. Just a few weeks ago I was out camping and a father/son duo died in their tent because it was raining out and they wanted to use the stove to warm up food.

</comment></comment></comment><comment><USER25> Cheap housing for Docker interns

</comment><comment><USER26> High rent in the Bay Area is primarily due to poor land use. Not only are most buildings very short, but there's a ton of unused land near 280. It doesn't make sense to solve a political issue with technology.

<comment><USER27> Ummm if by "unused land" you mean open space preserves, parks, amazing redwood groves, etc...then yes, there is "unused land."

Building out on those areas because there's currently demand over on that side of the Bay (because it's closer to Stanford and Sandhill road) would be a big time shame.

<comment><USER28> I thought the Stanford/Sandhill area surrounding 280 was undeveloped because the land is owned by Stanford. Not so?

</comment></comment></comment><comment><USER29> some more info:

[http://www.boxouse.com/](http://www.boxouse.com/)

Luke is YC

Here's a 28min video of him and Heather showing off the project back in October [https://www.youtube.com/watch?v=dfqunEuw61k](https://www.youtube.com/watch?v=dfqunEuw61k)

heard about this a few months ago and I find it pretty cool. if only the laws were more favourable...

</comment><comment> the-dude Student housing Groningen, for years already: [http://www.studenten.net/lifestyle/lifestyle/16842/wonen_in_...](http://www.studenten.net/lifestyle/lifestyle/16842/wonen_in_een_container_helemaal_zo_gek_nog_niet) ( Dutch with pictures )

</comment><comment><USER30> Neat project, but actual construction costs aren't what are driving bay area housing prices.

Edit: and looking at their website ([http://www.boxouse.com/](http://www.boxouse.com/)), solving bay area housing doesn't seem to be the actual business proposition.

<comment><USER31> So much BS in that website it's tough to read past the initial paragraphs.

</comment></comment><comment><USER32> Wow, so the response to squatters illegally living in a office building that is zoned non-residential is "you should figure out a way to make the office building legal to live in"?!

Either Ivy Lee's comments reflect a serious, willful, inability to see reality and enforce the laws, or it is simply a poorly thought through excuse for a willful choice to not enforce the laws. It reflects a deep dysfunction either way. A few precedents like that would make me very, very hesitant to purchase commercial property in San Francisco.

<comment><USER17> SF has been like this for decades. There is a reason why the entire bay area has this anti-development problem.

</comment></comment><comment><USER33> In one of William Gibson's Bridge Trilogy novels one of the main characters lives in a shipping container in Southern California. It has come to pass.

</comment><comment><USER34> Just build tall buildings. If Taipei and Hong Kong can do it, so can SF.

</comment><comment><USER35> Reminds me of JG Ballard's Billenium where an overcrowded world has people living in three point five square meter rooms that were subdivided out of any space possible. Basically a world where to get more space you had to get married and marriage required three children, all furthering the population density problems

[https://en.wikipedia.org/wiki/Billennium_%28short_story%29](https://en.wikipedia.org/wiki/Billennium_%28short_story%29)

</comment><comment><USER36> They should look into the container park in downtown Las Vegas (Tony Hsieh's pet project) which has been immensely successful - city codes and all! :)

</comment><comment><USER21> Those look like a death trap if there were a fire. I also can't help but think of Bubbles from Trailer Park Boys living in his storage shed.

<comment><USER37> It does seem like cooking on a campstove is not a safe choice, induction hotplates are cheap and powerful, assuming there's electricity.

</comment></comment><comment><USER38> I actually like the shipping containers. They're a bit expensive, but I guess at the rate of everything else it's about what you're gonna get.

</comment><comment><USER39> I smell another Docker pivot

</comment><comment><USER40> Maybe it's time tech companies let their engineers globally work remotely from comfortable places, instead of parking them into metal boxes and sweetening the deal with catered lunches.

<comment><USER41> +1 - However you'll find no love within the HN crowd. YC and many SV startups are vehemently against remote work. That's why I was stunned when YC allowed for new fellowship applicants to work remotely (so maybe it's getting better...?).

I think a lot of it has todo with ego, investor show-ponying and lack of solid culture. Beyond that many startups justify paying their employees like shit for small office perks like free lunch and couches. That type of stuff doesn't really work remotely.

<comment><USER4> I do understand the desire for co-located teams up to a certain point. Today, I certainly work outside an office more than inside. That said, I have a lot of trouble seeing how remote work would have been a net positive when I was starting out. Admittedly, technologies we had available for communication weren't as good then but that part of my career was so dominated by F2F interactions that it's hard to imagine I would have been as effective as a remote worker. (I was a product manager for mostly system hardware.)

<comment><USER41> I 100% agree. Remote working has really only worked for the past 5-10 years (probably less than 10).

Async chat tools, file sharing, conference calls, video chats, etc. are the lifeblood of communication at remote companies. Without those tools it's very hard to make remote working work.

People who say remote work doesn't work often times still rely on things like email...that's just not how it works. If you're communicating internally via email you're doing it wrong.

That's not to say tools define remote culture, but they certainly help reinforce it.

<comment><USER4> Today's tools are certainly better. We had conference calls (and internal-only email) but basically none of the other tools you list. And maybe if a company had a real remote worker culture, it would be natural to slip into it even as a new hire. It's just a bit hard for me to imagine based on my own experience. But, as I say, different time and different culture.</comment></comment></comment></comment></comment>


Ask HN: Why do I never hear of acquisitions outside of the U.S.? - <AUTHOR>

Or am I being lazy and not looking them up?<p>Or even an international hacker news where only things non U.S. are allowed? <comment><USER2> If you sign up for the newsletter at [http://tech.eu/](http://tech.eu/), you get a weekly email with all the EU acquisitions of that week & other interesting news.

For example, this was from last week mail:

What else happened in the European tech industry this week?

      M&A deals, IPO filings and rumours
      Denmark-founded Zendesk filed for an IPO of up to $150   million and acquired Singapore-based competitor Zopim
      The Netherland's Takeaway.com raised $103 million and acquired German competitor Lieferando
      Spanish travel company eDreams Odigeo opened for trading
      Vivendi agreed to sell SFR to Altice for $23 billion
      French ad tech company Criteo bought French startup AdQuantic
      French native ad tech platform Adyoulike acquired British content service and native network Content Amp for $2.5 million
      Munich's Deal United is insolvent
      Belgian HR company Prato acquired recruitment software firm Actonomy
      Ovum and Informa Telecoms & Media Research announced intention to merge
      Security solutions company INSIDE Secure acquired   Scotland-headquartered mobile payment security technology company Metaforic

</comment><comment><USER3> There have been a number of acquisitions of companies outside the US. Waze (Israel) by Google was the most recent and most high-profile. FlexyCore (also by Google) was a French startup. doo.net (German) got a serious offer from Dropbox but declined.

I think you're being lazy and not looking them up.

</comment><comment><USER4> There are lot of wonderful startups that don't get featured on HN.

* Little Eye Labs (Bangalore) got acquired by Facebook. [[http://techcrunch.com/2014/04/09/indias-flipkart-nears-330m-...](http://techcrunch.com/2014/04/09/indias-flipkart-nears-330m-myntra-deal-as-common-investors-push-to-fight-amazon-ebay/)]

* Flipkart (India's largest e-commerce store) is looking to acquire Myntra (India's best online apparels store). [[http://techcrunch.com/2014/04/09/indias-flipkart-nears-330m-...](http://techcrunch.com/2014/04/09/indias-flipkart-nears-330m-myntra-deal-as-common-investors-push-to-fight-amazon-ebay/)]

</comment><comment><USER5> I think most of the news sites, including Hacker News is really focused on Silicon Valley and NYC startups so unless there's company from outside US acquired to a hot US company, it's really rare for it to be in news.

One big acquisition lately outside US was SoftBank buying Supercell for $1.5B ([http://www.reuters.com/article/2013/10/16/net-us-softbank- ac...](http://www.reuters.com/article/2013/10/16/net-us-softbank-acquisition- idUSBRE99E0ID20131016))

</comment><comment> workhere-io A month ago I made a list of well-known Danish startups, and many of them have had US funding: [https://news.ycombinator.com/item?id=7391809](https://news.ycombinator.com/item?id=7391809)</comment>


Dot-com bust ripples still felt 10 years later - <AUTHOR> http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2010/03/06/BUK71CB0PV.DTL&type=business&tsp=1 <comment><USER2> The funny thing is that at least people back then dreamed big, even if it turned out to be stupid after the fact.

Now people just chase after social graph and all try to make money off it in some way or another. Can anyone point me to a startup doing something cool that has he potential to change the world?

<comment><USER3> > Can anyone point me to a startup doing something cool that has he potential > to change the world?

As cliche as it is to say it -- Facebook. Actually, they have already changed the world. How so?

I graduated high school in 1995. At the time, a few people had email, but we didn't really use it to stay in touch. When we graduated and went to different colleges, we pretty much lost touch. We might see these people during break, but I stopped going home at break.

I've reconnected with a whole bunch of high school friends thanks to Facebook.

And you know what? When you talk to kids that are graduating now, they don't identify loosing touch with their friends as a problem. Even if they go to different schools, they just check out Facebook, and they are all caught up. When they go home for break, they just pick up where they left off on Facebook the day before.

<comment><USER4> Not so sure about that. Online contact is way different from face to face contact and I don't know about you but when you have 200+ people on your friends list it turns into a different kind of social game than when you are hanging out with 3 of your best friends at the local pub.

</comment></comment></comment><comment><USER5> I just took a look at the startup they mention, flowtown.

By all appearances they're just scraping data from all the social networks, canonicalizing it based on email, and aggregating it.

Is there any possible way to do this without violating the services TOS's?

<comment><USER6> [http://blog.cubeofm.com/how-to-convert-email-addresses- into-...](http://blog.cubeofm.com/how-to-convert-email-addresses-into-name- age)

maxklein exposed the primary technique these guys are most likely using. It's definitely a TOS violation.</comment></comment>


Collecting and plotting live data with Go - <AUTHOR> http://nf.id.au/collecting-and-plotting-live-data-with-golang

<comment><USER2> Is there a demo running somewhere?

<comment><AUTHOR> If you watch the final 10 minutes of the referenced video, you can see it there. There is no way I can run a demo continuously as it uses all the resources of whatever machine it runs on.</comment></comment>