What happens if authorities seize your laptop? - <AUTHOR> http://www.bbc.co.uk/news/magazine-25458533 <comment><USER2> "Or you can scrub your laptop clean, storing everything on an external hard drive that you leave at home. Then you know you are safe from prying authorities, at least at the border."

That is unless you believe that those prying authorities have the will and the way to leave an undetectable backdoor in your laptop. Breaking the chain of custody in any laptop today is akin to destruction of trust in that device. Who is responsible then for paying for this damage?

<comment><USER3> I would second this. We know for a fact that the NSA uses BIOS malware. I don't believe we know for a fact that such malware is routinely installed by border guards, but it's not a very far-fetched worry at this point.

The technical expertise required to do so is very limited as long as you don't password-protect the BIOS: Basically, they only need to be able to plug in a USB stick and reconfigure the BIOS to boot from it.

In other words: If you leave your laptop outside of your physical control for even a few minutes, you may have to assume that it is totally compromised as long as you don't have a BIOS password.

If the laptop is outside of your control for a longer period of time, you probably have to assume that it has passed through the hands of somebody with sufficient technological know-how to work around the BIOS password as well.

<comment><USER4> Isn't BIOS passwords useless?

For non-soldered but socketed BIOSes I think one can just take chip out and put it into your wallet, possibly, covering some pins with some dissolvable insulating substance. For soldered SPI EEPROM chips with known pinout, I think one can reflash the chip afterwards.

<comment><USER5> BIOS passwords are not always useless, depending on model.

I had a Thinkpad T42 on which I managed to set a password for editing BIOS settings that I did not remember.

I the laptop into IBM for repairs to the monitor, and as part of their repairs they needed to get into the BIOS settings (I believe to run a diagnostic). Their solution was to replace the entire motherboard.

<comment><USER4> Well, guess it were hardware types, who performed the repairs, or they just didn't have necessary equipment (an AVR board like Arduino or PC with an old parallel "LPT" port will suffice, hardware-wise) at hand, so it was easier for them to solve it that way. :)

I was 99% positive the same could be achieved by messing with EEPROM. And, indeed, less than 10 minutes of searching yielded this unsurprising result: [http://arduino.ada-language.com/recovering-ibm- thinkpad-t42-...](http://arduino.ada-language.com/recovering-ibm- thinkpad-t42-bios-password-with-avr-ada-and-arduino.html)

tl;dr: Nope, T42's BIOS password is _not_ secure if you allow anyone with necessary hardware to touch the motherboard for a minute. TPM may (depending on the laptop model and firmware revision) prevent password recovery but will likely not prevent anyone from resetting them - at least this seems to be the case with Thinkpads. Next time I'll clean dust from my X300, maybe I'll remember this thread and check its EEPROM too. :)

So, do _not_ rely on BIOS passwords as a strong security measure.

</comment></comment></comment></comment></comment><comment><USER6> Activists and other "interesting" people have their own particular security problems.

For most of the rest of us, we really have no data of any interest to the authorities. That doesn't mean we shouldn't care about data security, if that's important to us. But it's not the real problem with border confiscation.

The real problem is not having your hardware or software tools at your destination.

So don't bring any hardware or data that you can't afford to lose. Certainly don't bring anything that you're emotionally attached to, particularly inbound.

Either don't bring anything, and buy it all at the destination, or just bring the cheapest stuff you can use productively, and be prepared to replace it at the destination.

The NSA already has my email. But I'd hate to be without a camera, or phone, or laptop, or data, or whatever other tools I was going to use at the destination. Plan for that, it's the more likely and practical threat.

</comment><comment><USER7> Is it possible to encrypt two files together with two different keys? Say I have my class notes from freshman Latin and I have my plans to take over the world. I encrypt them together into a single file "dont_read_super_secret.encrypted" and if I enter "fuzzykitty98" as the key then I see only the notes. But if I enter "downwithfreedom2000" then I see only the diabolical plans. Is that possible?

If anyone builds this app, I'd like a slice of the pie, please :-)

<comment><USER8> It'd be possible but difficult.

I don't know how to do it without some kind of markup / document system (no morning coffee yet). I figure it wouldn't be that hard.

You could use a TDMS file(v1), which each channel is an item. When ran you give the program a password, which it checks against each channel, calculating the salted hash of your password. When it finds a matching hash it decrypts the document (saved as data within the channel).

This gives you a lot of plausibly defensibility because nobody understands TDMS file structure, not even people who work with them (it is an open standard, just nobody cares). And secondly, you decrypt the document and you get something out, even if that something isn't exactly correct.

I could likely push out a windows version by Saturday I guess if you don't mind it'd be using SHA-256 instead of [b/s]crypt for password checking. Maybe future updates to include some form of internal compression + some type of signing who last modified the document(s).

<comment><USER7> Knock yourself out. People will be buying anything that they think can keep their data safe, so someone may as well come up with a decent solution. We can build it and let the HN community battle test it. Split on profits can be 60/30 as you're doing the work :-)

<comment><USER8> Battle testing is a horrible way to prove crypto works, from the outside looking even horribly done crypto looks secure.

<comment><USER7> Yes, comments like this actually are what I'm looking for. We need to develop real tests.

<comment><USER8> The only real test is to make it open source. There isn't a lot of money in cryto done correctly, that is closed source. Because without public audits its impossible to know you've done it correctly, and even if you have, the public perception will be you haven't due to its closed-source-something-to-hide nature.

<comment><USER7> Makes sense to me. I've always wanted to get involved in a cool open source project. Anyone want to get this started? Make it a free time activity or something? Or are there already better solutions out there? No need to reinvent the wheel.

<comment><USER8> Not in this direct line of software of the encrypt multiple documents and only out 1 based on pass-phrase, this would be unique (as far as I can tell).

True crypt tells you how to set this up, but not do this automatically. Also it would require you selecting which volume, not just "insert password get document"

This would offer a higher degree of plausible-deniablity, and portability, by making it a file its not tied to one location. The structure of the file, and multiple hashes also grant plausable deniability why you can't just decrypt the entire file in one go and compare the 2 documents SHA hashes.

Would it stand up in court? No. It would help avoid less tech savvy people.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> A frightening thought: if it was practical to search _each and every device_ going through the border, they probably would do so.

Happily enough, statistical sampling techniques can make that possible [1].

[1] S. Garfinkel. Searching A Terabyte of Data in 10 minutes. [http://simson.net/ref/2013/2013-01-07%20Forensics%20Innovati...](http://simson.net/ref/2013/2013-01-07%20Forensics%20Innovation.pdf)

</comment><comment><USER10> I don't travel with any hardware other than a DSLR and then I mail the SD cards home. I'll use internet cafes and my phone and that is it.

It gets broken, searched, x-rayed, fucked up and generally treated like shit.

At Zurich airport, they managed to break my old IBM T42. Had to get my company at the time to courier a new one overnight from the UK by road which cost £1150 just for the courier.

</comment><comment><USER11> "During their inspection of your laptop, the authorities will disregard files that are not germane to their investigation, says Rosenzweig, explaining that the official policy is to 'flush all non-criminal data'."

How exactly do they tell the difference, what if I use steganography to hide stuff in my family pictures? They won't flush anything, they will keep everything in case it's relevant.

</comment><comment><USER12> > Between October 2008-August 2009, for example, more than _220 million people > travelled to and from the US_ , according to Department of Homeland Security > officials.

> During that time authorities searched about _1,000 laptops_ carried by > travellers.

We don't live in the police state that most Snowden and Kim Dotcom supporters here tell us that we do.

I get really tired of seeing anecdotes used to represent the average.

<comment><USER13> Tangential. One of the reason I love "V for Vendetta" is how it shows how normal it is to live under a dictatorship. Thing is, for most people, there's almost no difference, mainly during the most recent dictatorships. But for a very particular minority, life is very very different. I should know, I'm currently in a country where 50 years ago there was a dictator and it's not uncommon for normal people to claim how things were maybe better during those decades. Well, my grandfather, tortured by the state police for being part of an union, wouldn't agree. But for the other 99% of the population, life was, give or take, just as it is.

<comment><USER12> > But for a very particular minority, life is very very different.

That's pretty much true for any and every society.

<comment><USER13> Can you expand on that?

</comment></comment></comment></comment><comment><USER14> This has been the case for some time, and I doubt the unaccountable bureaucracy is going to change. So the only thing we can do is disrespect, mitigate, and undermine.

Here was my ad-hoc procedure from traveling internationally a few months ago (tourism), with a prior of not really expecting to be hassled on the way there, but unknown for the way back:

1\. Choose the laptop I'm least likely to miss in the case it gets stolen by JBTs, with respect to the functionality I require.

2\. Wipe(1) the first 10MB of disk (has only ever been LUKS), then one /dev/urandom pass into the entire thing. (In retrospect, zeros may have been better than random)

3\. Reinstall Debian, with a passphrase I don't mind giving up. Sync over only files that I don't mind giving up.

4\. Go through Japanese customs - the only question asked was "Are you with him?" (friend in front of me).

5a. At this point, I possess a still uncompromised machine at the destination, with stored ssh host keys, etc. When (last-minute) prepping, this possibility didn't quite occur to me. Not being prepared to take full advantage of this was regrettable.

5b. (If machine had been molested, I would have not logged into my privileged accounts at all. For the most part I didn't have to anyway, but since I wasn't fully prepared it came in handy once or twice)

6\. For return, wipe first 10MB of disk again, then one /dev/zero pass to the entire thing (so there was no argument that I had encrypted data). Then mkdosfs on a whole-disk partition for derp-nothingness. (This was done with a Debian install image written to an old flash drive I had with me for the purpose. My only concern at this point is the hardware getting stolen.

7\. Take hard drive out of laptop so that it is a separate device. This would most likely increase suspicion, but make them even less justified in stealing the whole machine (not that this would stop them).

8\. Get waved through coming back through USG because laptop "searches" aren't actually that common for people not on the primary watchlist (everyone is on the secondary watchlist). Still, I will do the same thing next time, and think it irresponsible to not.

There are of course improvements that could be made to this, including a small default-booting "nothing to see here" install, with file times etc automatically adjusted. Automatic copying of machine credentials etc when you're at your destination. Using a separate partition instead of the flash drive. And of course automation of the process so it's easy for everyone to do :)

<comment><USER15> What tools could be used to boot off a trusted, non-writable USB stick to checksum the BIOS?

Difficulty level: Macbook Air

<comment><USER14> Well, that's a completely different problem. If you travel frequently and your gear gets stolen for a few days at every border crossing? At the very least, I'd look into a laptop that was easily field-strippable, and figure out how to verify non-volatile storage with an external device, at least on return. And never fully trust the machine again either. Note that this problem is what TPMs purport to solve, but that doesn't help you against a major government which will demand a backdoor from the manufacturer.

My laptop was never touched by customs - had it been, my plan was to never trust the machine again.

Most people are in my situation - never actually getting hassled but wanting to protect themselves now that the gloves are coming off. In the future we all may have to deal with device quarantines of a few days at every crossing (what a boon to local sellers!) but that's not now.

</comment></comment></comment><comment><USER16> Hardware is cheap in the US, I'd leave my laptop at home and get something cheap (either a Chromebook or a used laptop), then access/transfer data and configuration over the net.

As for my phone, if I were in a position to be worried about customs installing backdoors, I'd prepare a recovery zip beforehand with all my data, then download it from my own server or a secure storage, and flash it after passing customs. Or better yet, travel with a SIM and buy a cheap Moto G, the resale value alone once back at home would make up its US price.

</comment><comment><USER17> Such an inconvenience. They should reimburse the cost of the laptop say to standard tune of 3-5k government cheques and allow for you to pick up your laptop in return for the money, if you need it.

Full on encryption, tmp lock and filesystem hashing via tripwire then is mandatory. Fun thing is that you can screw up the malware to send all kinds nasty shit back to them, like trojans and viruses, PIF files and EXE files and whatever might tickle your fancy. Then get your malware do maximum damage on their network.

After all they hacked your laptop, they engaged in illegal activity and it is only fare for you to punish them to the fullest extent of your technical capability.

They cannot acknowledge the fact that they hacked your laptop without a warrant.

etc.etc.

There's tons of fun to have this way. Since people who are doing these things are expecting you to be retarded luser and so you can set a trap and have them fall straight into that.

Make a blog post and example of malware and how to entrap the said trespassers, what does malware do etc.

my 2c.

</comment><comment><USER18> I have seen the corporate response of only providing remote desktops via browser and SSL to foreign (US) deployed personnel. Means the data never physically crosses the border.

No clear players in this market for consumers though. Where is the consumer remote desktop via browser+SSL that doesn't rely on a US hosted cloud service?

<comment><USER19> >Where is the consumer remote desktop via browser+SSL that doesn't rely on a US hosted cloud service?

The one you host on your own infrastructure?

<comment><USER18> Which software? Remote Desktop + SSL.

I don't know of a good self-hosted combination for that.

</comment></comment></comment><comment><USER20> You can hide your (encrypted) Micro SD cards inside fake nickels:

[http://www.amazon.com/dp/B006BFCOIE](http://www.amazon.com/dp/B006BFCOIE)

But really, it's safer to not physically carry data across the border, but to access it over VPN or another secure tunnel while abroad.

</comment><comment><USER21> oh so, we must upload custom encrypted files somewhere obscure and scrub our electronics before traveling; then download them again after we reach our destination. and then this border seizure non-sense is really a waste of time.

</comment><comment><USER22> There is vague sentence "Afterwards you get your laptop back ", but not much else. Perhaps it would be worth to create serious article on subject.

Who pays for damages?

If harddrive is separated from laptop, does it get seized as well?

What if I have 100GB of random data on hdd?

Is there obligation to provide technical support to officers? Not everyone knows howto boot FreeBSD without bootloader.

Do I get written certificate of what was seized? There could be some bitcoins on hdd...

</comment><comment><USER23> 1\. Backup your documents on Dropbox/GDrive/Whatever (edit: can be you personal server. You can use Truecrypt, and not upload your datas uncrypted. The point is that you must not have the datas on your pc when you pass the border).

2\. Wipe your PC.

Optional 2.5. Download a bunch of fake personal files.

3\. Pass the border.

4\. Access Internet.

5\. Download your datas.

<comment><USER24> With the recent history of topics here about the NSA having back doors into providers of services how is uploading your data where you suggest actually going to protect you?

If anything, I would go to the point of screwing with border agents by having tens of thousands of pictures of my dogs, kids, flowers, and whatnot, all with naming similar to PICnnnnn or whatever is the current default of most digital cameras. Having them given the wrong doc type would be a nice touch too.

Of course why not store your data on a SD card and just pop it somewhere they are not bound to look?

<comment><USER25> Make sure you include a few vanilla porn pics and only slightly embarrassing drunken party photos. If they don't find some evidence of vice, they will suspect it was just staged data, and they might keep digging.

<comment><USER26> When border patrol agents are looking for narcotics, do you honestly think they pass over the guy carrying rolling papers in favor of the one carrying nothing remotely suspicious due to lack of evidence of vice looking "staged" in the latter case? What's different about a porn- and photo-free hard drive full of boring business reports and uninteresting browser histories?

<comment><USER25> If they are seizing and searching your laptop, it isn't because you're violating ITAR or carrying dual-use spreadsheets. There are few legitimate reasons why the authorities should be at all interested in the data on your devices when you are entering an area where both free speech and privacy are considered rights.

Among other goals, they are assembling profiles on dissenters, to be used against them later. If you give them something that appears legal but still potentially embarrassing, that's disinformation that might save you from a stronger attack later.

This differs from a narcotics search in that having data on electronic devices is not a crime. They could not perform such a search anywhere but at a border crossing.

</comment></comment></comment></comment></comment><comment><USER27> Can the authorities ever compel you to provide a password?

<comment><USER28> in the uk you can be imprisoned (up to 2 years) for not revealing your password. i am surprised the bbc didn't mention that (maybe i missed it?)

[http://en.wikipedia.org/wiki/Key_disclosure_law#United_Kingd...](http://en.wikipedia.org/wiki/Key_disclosure_law#United_Kingdom) (also contains details for other countries)

</comment></comment><comment><USER29> So is the only correct answer to package the hdd in a sales package, then send it and the laptop separately with UPS or DHL in and out of the country?

</comment><comment><USER30> From what I hear, SSD's can't be wiped completely, so be careful with such laptops (Macbook Airs, etc).

<comment><USER31> Theoretically true, but practically misleading.

Each block of flash can be written only a limited number of times, so flash drives (SSDs, cards, USB sticks) all have more blocks than are visible as part of the disk. Drives internally rotate active blocks in and out of the spare pool to try to keep the number of writes to each similar ('wear levelling'). When you write to a flash drive — including trying to overwrite data to destroy it as someone might on a magnetic disk — it will generally pull a block from the spare pool for the new data, and put the old block in the spare pool.

The spare pool is invisible to the OS, but it is reasonable to assume that there are 'secret' commands to access it — not because some TLA demands it, but because the hardware/firmware engineers need it for development and debugging.

BUT there is a great big BUT. Writing flash is a two-step process. Programming flash can only change a 1 bit to a 0. Before this, there has to be a slower erase step, that sets the block to all 1s. In order to avoid this performance- killing overhead on every write, flash drives erase as much as possible (whether spare pool blocks or TRIMmed visible blocks) in the background as soon as possible.</comment></comment>


New study finds evidence that prestige increases testosterone levels in men - <AUTHOR> https://www.psypost.org/2018/06/new-study-finds-evidence-prestige-increases-testosterone-levels-men-51591 <comment><USER2> How human does the prestige have to be? I wonder could this affect also happen with online gamers? possibly even with human vs CPU games?</comment>


Radical Honesty 8 Day Workshop: "The Curse in Honesty" - <AUTHOR> http://www.radicalhonesty.com/workshops.html

<comment><AUTHOR> I'm particularly interested in your reactions to the section describing the 8 Day Workshop.</comment>


You Want Some Advice? - <AUTHOR>

"If you want some advice, you've probably been thinking for a while. Stop doing that, and go make something already. Stop looking for advice. Stop waiting for inspiration to strike. Stop reading stupid productivity books, business books, start-up books, business magazines (unless it's Harvard Business Review — that's a good one), dumb-ass-top-5-whatever blog posts, and use the common sense you've already got and make something. The only way you're going to get somewhere is by going somewhere. Put your pencil on the paper and go. That's it."<p>Loved this quote from my friend Erin. Too true. <comment><USER2> TL;DR = "Just Do It"

</comment><comment><USER3> yes, make it work first!</comment>


Challenges in Large FPGA-Based Logic Emulation Systems - <AUTHOR> https://dl.acm.org/citation.cfm?id=3177542 <comment><USER2> Its always the same set of problems. FPGAs take too long to synthesize, place and route. Not much internal visibility or its not trivial to dbeug. not enough capacity as chips are becoming bigger and bigger.

<comment><USER3> > Its always the same set of problems.

Nope. Did you read the article?

<comment><USER2> No. Its paywalled. But I work on making Emulation systems for a living. So, I know this for a fact.

<comment><USER4> There is a small PDF button that lets you read the article. And you are correct, nothing new in that article.

<comment><AUTHOR> Don't think the small PDF button works. It's paywalled.

</comment></comment></comment></comment></comment><comment><USER5> Paywalled. Scihub has it (DOI: 10.1145/3177540.3177542)

</comment><comment><USER6> Why even post this if the article has to be purchased?

<comment><USER7> I hate paywalls as much as anyone else, but it's just too common with papers to restrict HN to free only, however you can use scihub easily enough... the latest GDPR geoblocked newsites on the otherhand are very unwelcome.</comment></comment>


C++ - The Forgotten Trojan Horse - <AUTHOR> http://ejohnson.blogs.com/software/2004/11/i_find_c_intere.html

<comment><USER2> Always useful reading for anyone who thinks C++ is great and can't understand all the curmudgeons who think otherwise:

<http://yosefk.com/c++fqa/defective.html>

The rest of the FQA site is good too, but the summary is the best enumeration of all the brain damage.

<comment> old-gregg Believe me, those who _truly_ believe that C++ is great, consider some of those deficiencies to be advantages.

It helps to remember, that C and C++ don't exist on an "VM island", i.e. as an isolated process, like all high-level programming languages do. They are effectively extensions of UNIX-derived operating systems, i.e. they run under "UNIX VM". They even have a garbage collection of sorts: when you exit the program, the memory gets freed. And, according to Linux philosophy, launching processes or forking/dying should be quick, efficient and, in fact, desirable. Also, having many independent binary modules is the norm, so here is your runtime encapsulation.

But C family is still the only tool out there that allows you to extend an OS, i.e. for instance to build a piece of code, a _single instance_ of which will be serving _all other simultaneously running processes_. This explains why Apache eats so little RAM. None of VM-based languages can do that. It's called systems programming.

Building a web-based CRM in C++ is stupid. Building a filesystem in Python is impossible.

<comment><USER3> It's nginx that eats so little RAM. Apache is a huge!

<comment><USER4> And nginx is written in C

</comment></comment></comment></comment><comment><USER5> Linus Torvalds thoughts on C++:

[http://thread.gmane.org/gmane.comp.version- control.git/57643...](http://thread.gmane.org/gmane.comp.version- control.git/57643/focus=57918)

<comment><USER6> Those aren't his thoughts. Those are his thoughts morphed into a flame meant to stop people from bugging him about a particular decision he made that he believed was correct and didn't want to revisit ad nauseam.

<comment><USER5> Can someone post a link to his actual thoughts on C++?

<comment><USER7> <http://kerneltrap.org/node/2067>

<comment><USER8> > _the whole C++ exception handling thing is fundamentally broken_

While I completely agree that using C++ in the kernel is not the brightest idea, I _am_ curious what's so fundamentally broken about C++ exception handling. It certainly comes with performance penalties, sometimes considerable (especially on the fast paths), but why is it flawed _fundamentally_ ?

<comment><USER9> One thing that I consider fundamentally broken is throw-lists: if a C++ function _ever_ throws an exception that is not in its throw-list, the program _terminates_. (The only way to avoid this is to omit the throw-list entirely, so I always omit it.)

There are of course a few things wrong with this design.

One is that _even deeply nested exceptions_ count; so if you've vetted your code and listed every exception that _you_ throw, you're still screwed if you call a function that eventually throws something else.

This of course leads to the next problem: code evolves. Suppose you did somehow review all possible code that your function will touch, and wrote an accurate throw-list. Then next week, Jim goes into one of those buried routines and makes it throw something new; boom, you are once again at risk of terminating.

Yet another problem: suppose the messed-up throw list is in a library. Not only does this mean a library is responsible for exiting your program at a completely inappropriate point, but it might be a library that you can't easily change. So you're forced to declare implementation-specific exceptions that have no meaning to your callers. (Or just don't declare, as I do.)

The real issue of course is that terminating is a stupid behavior, _even though_ they define terminate() to give you a point of interception. There are all kinds of reasons why you might accidentally mess up a throw-list, and since all you really gain for "fixing" this is a little code purity, it hardly seems worth dealing with severe runtime errors.

</comment></comment></comment></comment></comment></comment><comment><USER10> This should be required reading for anyone trying to push a new language in a Java/C# shop. Don't fight the platform, instead, leverage it to your advantage.

</comment><comment><USER11> This article is equating anything that is feature rich and highly competent to being a Trojan Horse. If so, then bring on the horses!

</comment><comment><USER12> This is the same strategy that Clojure is now using, which is why it's the only LISP that has any chance of going mainstream.

<comment><USER5> I don't think Clojure uses the same "trojan horse" strategy, i.e. it isn't a superset of the Java language with Lisp extensions.

It does use the Java virtual machine, however, which allows it to use existing java libraries.

<comment><USER6> Implementing Java interfaces and subclassing Java classes does allow Clojure programmers to introduce Clojure into a Java organization without forcing the Java programmers to accommodate them in any special way.

(That is, as long as Clojure code can be deployed easily as jars, and as long as Clojure doesn't create any special classloader problems because of its runtime system. Those are problems that bit me hard when I used Jython code in the Eclipse plugin framework, and I imagine any dynamic language might accidentally create classloader problems unless it was specifically designed to avoid them.)

</comment></comment></comment><comment><USER13> Look at all that comment spam. How lovely.

<comment><USER14> Yeah.

Great post, but the comment spam shows that this site isn't very well maintained. Clearly the author hasn't spent much time on it in a long time.

Too bad.

</comment></comment><comment><USER15> This article is silly. The real reason for the rise of C++ is that "C with Objects" fit the metaphors that GUI libraries need a lot better than C.

And in the end...it's not such a bad language. In the real world, you only use a small part of it on any one project. In the real world, your framework or libraries matter more than the language anyway. And in the real world, performance always matters in the end.

<comment><USER16> I don't agree on the last. In the "real world" that I am familiar with, performance is often irrelevant. Lots of programs get written that don't need to run fast or don't do enough work for performance to be an issue.

<comment><USER15> Well, if we're talking "programs" as opposed to administration glue scripts, I see very few fields where performance doesn't matter. It matters for online apps. It matters for GUI applications. It matters for games. It matters for scientific software. Operating systems. Embedded apps. I suppose there are some enterprise business niche software fields somewhere where it doesn't matter -- until someone decides to write some competing software and sell it, that is.

<comment><USER16> Wow, quite the load of BS ego there. The average page in the wide-wide world is seldom visited and its performance doesn't matter. There are any number of GUI programs I use that are just utilities whose performance matters very little. And, yes, there is plenty of business software that needs to do its job correctly but where the performance is unimportant, or nearly so.

Kind of disappointed in HN for rating you up. Just goes to show...</comment></comment></comment></comment>


Show HN: ConvoBox – Get useful anonymous feedback from your team in Slack - <AUTHOR> http://www.convobox.com <comment><AUTHOR> We've been looking for a better way to give and get feedback on our teams (I've been yelled at once too often for giving a candid "I'm not sure that's a good idea" to a manager).

We built this so that teams can have real input and feel safe, while managers can get early warning on problems. What do you all think?</comment>


Ask HN: What keeps you going? - <AUTHOR>

I suppose everyone goes through times when it's near impossible to get anything done. Many of you on HN have reached success, or are working your asses off to get there.<p>What do you all tell yourselves that keeps you motivated? What thoughts drive you? Do you have heroes whose footsteps you're following? Maybe it's something else that pushes you, but whatever it may be, please share. <comment><USER2> Maybe it's time to dabble in something new?

I've developed many interests over the years -- programming, game design, interactive development, music theory, soundtracks, cooking, martial arts, hiking, circuit bending ... I may not have mastered any of these, but my mind feels limber. I've stopped feeling guilty about putting down a project, and revisiting it later. That's how I get around mental blocks and ruts. It's always nice to revisit something with a clear head; old roadblocks tend to sort themselves out.

Also, your interests can be combined in clever ways. I just finished a new iPhone app, which combines many of the aforementioned. (Shameless plug: Twang is an expressive handheld guitar: <http://tinyurl.com/twangapp>).

To me, this is success -- not making scads of money (necessarily), but rather having a job I love, and the freedom to pursue new interests.

</comment><comment><USER3> Fundamentally what's keeping me going is that I see a big market opportunity.

But on a day-to-day basis, when I really hit a brick wall, I take a break.

I have a "small items to-do list". It's a list of things that individually would take a short amount of time (say 5min - 3hrs) that I'd like to do "some day". I do one. Or two. Or 10. This clears my mind and also makes me feel productive. Also, it's a good break so that when I do get back to the big thing I'm chasing, I come back with a clear mind and fresh eyes so that I figure out a way around the brick wall.

Exercise, cooking, watching TV, and other activities also help. Just do what you feel like doing to re-group and re-energize, and then get back at it.</comment>


The Internet of Things is looking for its VisiCalc\\ - <AUTHOR> https://medium.com/@dconrad/the-internet-of-things-is-looking-for-its-visicalc-1a4b0e95c22a#.fcpfpywwc <comment><USER2> Is IoT missing the corporate connection? Because VisiCalc is what got _companies_ interested in microcomputers.

It was not, however, the first piece of software which made the microcomputer useful. Credit for that should go to Electric Pencil (1976), the first word processor for microcomputers, released three years before VisiCalc (1979).

WordStar (1978) also came out before VisiCalc.

So, perhaps IoT is really missing its Electric Pencil?</comment>


Google Prompt streamlines two-step verification with tap to approve - <AUTHOR> http://googleappsupdates.blogspot.com/2016/06/new-settings-for-2-step-verification.html <comment><USER2> I'd like to have a security key and prompt enabled at the same time.

<comment><USER3> That would make it a 3 factor instead of 2 factor authentication</comment></comment>


Ask HN: Can AWS Lambda do these two things? - <AUTHOR> Hi, I'm having trouble understanding AWS Lambda and after reading God knows how many websites I am even more lost.
Can lambda run PHP?
Regardless of the language - can a lambda function connect to a dynamodb, token exists get values from the db - then using these values connect to an API and return a json file? <comment><USER2> PHP support for Lambda is not official. I've seen projects, like Apex, that support non-standard languages using a hack-y method of executing a binary using Node or something. If you want PHP support for Lambda, you're better off with a third-party service like IronWorker.

Lambda functions can connect to DynamoDB, connect to an external HTTP API, and return a JSON file.

</comment><comment><USER3> Why would you want to run PHP over lambda? Lambda is best at taking an input, processing it, and returning an output (or triggering another function).

<comment><USER2> > _taking an input, processing it, and returning an output_

That's what all software does, if it does anything at all.

<comment><USER3> My point was that it doesn't do rendering, I'm sure you know what I mean if you know how lambda works.</comment></comment></comment>


Introducing PIXEL - <AUTHOR> https://www.raspberrypi.org/blog/introducing-pixel/ <comment><USER2> Looks nice, but I'm not thrilled about the changes to the sides of the windows for resizing. (The resize handles are on the outside now)

I am thrilled that they've moved wifi controls into the main menus and have put icons in for overtemp and undervolt measurements.

I've been trying very hard to stay away from Chromium browser, sorry to see it's the default, but at least they still load Epiphany.

Waiting for PiBakery to have the newest versions available before I give it a full tryout.

</comment><comment><USER2> PiBakery announced they have the new images up. Pulled it down, did the PiBakery build ( really sweet way to set it up) and I was good to go.

Desktop looks very nice, feels smooth on both a Pi2 and Pi3.

It's nice to that VNC server is now part of the build.

All in all a nice release.</comment>


Kindle Fire HD: Much Better Than Original Kindle Fire - <AUTHOR> http://www.useit.com/alertbox/kindle-fire-hd-usability.html

<comment><USER2> Original Kindle Fire owner here:

As a Kindle for reading books, it's great. Certain apps (limited due to it not using Android market) are great. Browsing any webpage? Awful experience. Youtube? Annoying, because you are stuck using the crappy browser instead of a dedicated Youtube app. I would like it much better if Amazon didn't fight so hard to keep Google anything off of it. After using my brother's Nexus tablet, I wanted to cry going back to it.

<comment><USER3> For what its worth, you can side load APKs on an unlocked Kindle just like any other Android device. Obviously that still doesn't get around not having access to Google's own apps like Gmail though.

<comment><USER4> I also have the original kindle fire onto which I have installed a custom ROM of Android 4.1. I am quite happy with it although I do wish it had a microphone.

</comment></comment></comment><comment><USER5> These reviews are really helpful.

Many reviews in the popular press ignore the overall experience and focus on minor technical differences (e.g. a tenth of an inch difference in thickness). Reviews focusing on the overall experience are on order of magnitude more useful than the "list of specifications" review.

</comment><comment><USER6> Good review, but I thought the bit about the back button was strange:

 _There's also a Back button (and a Forward button, when applicable). The entire platform's usability is much enhanced by the universal nature of this Back button. Consider this typical scenario:

You're reading an email message that contains a link to an article on a website. You click the link and read the article. You now want to return to continue reading the email message. Now what? In most systems, you have to close the web browser and find your own way back to the email program, hoping that it still displays the message as you left it. With the universal Back button, you simply click Back, just as you would when you tire of a web page. Backtracking works across applications, as it certainly should, because that's how users think._

This really only seems to be true if compared against iOS. But pretty much everything else on the planet supports some way of getting back to where you started, even if it involves launching another application then simply switching tasks back to where you were (e.g. Windows or OS X).

<comment><USER7> Isn't that what "find your own way back to the email program, hoping that it still displays the message as you left it" means?

<comment><USER6> Sorry, I probably should have focused it more on this

"In most systems, you have to close the web browser and find your own way back to the email program..."

which isn't really a true statement other than iOS.

</comment></comment></comment><comment><USER8> "the $199 Kindle Fire HD 7-inch offers much better value than getting the $329 iPad Mini, unless you need an app that's only available on the latter."

this sentance made me want to rush out and buy one, but I'm curious on how it compares to the also $199 Nexus 7...?

it seems like the nexus 7 is still a much better option.

<comment><USER9> It's all about ecosystem, if you have an Amazon Prime account you get the best experience with the Kindle Fire, if you want a more general use tablet with direct updates from Google go for the Nexus 7.

<comment><USER10> Kindle FreeTime Unlimited for kids seems like a home run for Amazon that Google won't be able to match. (Basically unlimited content for $3/month/kid + $80/year for Amazon Prime which includes lots of other Kindle bonuses.)

[http://www.amazon.com/gp/feature.html?&docId=1000863021](http://www.amazon.com/gp/feature.html?&docId=1000863021)

My only reservation is the extra work required to get Google Apps (specifically Google+ Hangouts) up and running.

<comment><USER11> The FreeTime program is what got a KF in the door of our all-Apple household. As far as I'm concerned, this makes it THE toy for families.

<comment><USER12> Is any of of this available outside the US?

</comment></comment></comment></comment></comment><comment><USER13> I got a Fire HD last week. I'm usually forgiving of devices but I haven't been impressed. The form factor is slightly nicer than the iPad Mini but in terms of the user experience/usability it's not a patch on the iPad. The screen is high res but surprisingly 'glary' in comparison (enough so I have to read white on black or the text seems to shimmer).

Pretty stunning, however, is the sound (the best quality I've heard on such a small device) and the picture quality for video. So as a general purpose tablet for a light user, I'd recommend it. But if you have the money, the iPad is better. And if you just want to read, the Kindle Paperwhite is miles better.

The Fire really only wins if you want an all in one that's cheaper than an iPad and you're not fussy about UX, but perhaps I underestimate the value of it being a great video playing device as I don't tend to watch any video other than YouTube (and YouTube is not very good on the Fire HD).

</comment><comment><USER14> Anything's better than the original Kindle Fire.</comment>


Linux Cryptography: Speck's real standing with the academic community - <AUTHOR> https://www.spinics.net/lists/linux-crypto/msg33291.html <comment><USER2> I must be misunderstanding something - why would a standards group (or anyone with a functioning brain) accept a "secure" cipher standard developed by an organization who's foundation in part is to be able to break encrypted communications?

<comment><USER3> Because you don't have to believe them or even trust them, it's maths. If their design was sound and well justified I don't see why it should be discarded. As pointed out in this email it seems far from being the case however.

After all AES is endorsed by the US government as well (although not designed by them, admittedly), yet we trust it because we have no reason not to.

While the NSA has an obvious incentive to be able to break encryption they also have an incentive to be able to use ciphers than are fast and not easily broken. Well, I suppose ideally they'd like a cipher that only they can break, which might be what's going on here.

So while I don't think NSA's proposals for a new cipher shouldn't be dismissed merely because it comes from them it should obviously be met with the highest amount of skepticism and scrutiny. No stone left unturned. Fortunately it seems that's exactly what happened there and the ciphers were rejected.

<comment><USER4> > it's maths

That's a joke. First off, we don't even know how NIST obtained this "magical" large number that we're supposed to trust it creates a safe formula for the P-256 curve:

y^2 = x^3-3x+41058363725152142129326129780047268409114441015993725554835256314039467401291

[https://safecurves.cr.yp.to/](https://safecurves.cr.yp.to/)

Second, the NSA _refused_ to reveal certain technical details that they _should have been able to reveal_ to the ISO: [https://www.theregister.co.uk/2018/04/25/nsa_iot_encryption/](https://www.theregister.co.uk/2018/04/25/nsa_iot_encryption/)

So it's not all "just maths". Otherwise all of these people wouldn't be so suspicious about it.

It's not all about the design, either, even if it was 100% transparent. But about how secure it actually is. We don't really know how secure an algorithm is, even as it passes a competition or standardization process. We have to see it in the real world, but once it's in the real world and everyone adopts it, it could take at least 10-15 years to get rid of it from most places.

The NSA refused to reveal how Simon and Speck would resist against certain attacks. They kind of did the same with IPSEC, where they made it super- complex so that the implementers would almost always get it wrong, which means they'd leave holes in there that the NSA could exploit. This is how they muddied the waters in the standardization processes. It's their MO when they can't introduce an actual backdoor - they just design a crypto algorithm that looks okay on the surface, but hides high potential dangers:

[https://www.mail- email@example.com/msg12...](https://www.mail- firstname.lastname@example.com/msg12325.html)

Also this seems to perfectly describe how I've already thought the NSA would act. Why would anyone ever trust them when they act like this? It's quite strange to still see so much support here despite of this:

 _> When some of the design choices made by the NSA were questioned by experts, Ashur states, the g-men's response was to personally attack the questioners, which included himself, Orr Dunkelman and Daniel Bernstein, who represented the Israeli and German delegations respectively.

> Ashur further alleged that the NSA had plied the relevant ISO committee with > "half-truths and full lies" in response to concerns, and said that if the > American delegation had been "more trustworthy, or at least more > cooperative, different alliances would have probably been formed."

> Instead, he says, "they chose to try to bully their way into the standards > which almost worked but eventually backfired."_

[https://www.theregister.co.uk/2018/04/25/nsa_iot_encryption/](https://www.theregister.co.uk/2018/04/25/nsa_iot_encryption/)

<comment><USER5> The NSA didn't make IPSEC super complex; the NSA didn't design IPSEC. The IETF did a perfectly serviceable job making IPSEC inscrutable, difficult to analyze, and complicated to implement all on its own. Accomplishing stuff like that is one of the IETF's great talents.

</comment></comment></comment></comment><comment><USER5> I'm not qualified to challenge Tomer Ashur's analysis of Speck and Simon, and I don't think ISO has any business standardizing those algorithms, so Ashur and I reach the same conclusion about the NSA ciphers.

But I think Ashur is overstating his case.

Ashur repeatedly alludes to the potential for backdoors in Simon and Speck, but never really engages that subject in any detail. That's unsurprising, because the NSA ciphers are both extremely simple, streamlined block cipher designs. There isn't a lot of room in them to insert a "backdoor". Ashur notes that these ciphers were sponsored by the same person that sponsored Dual EC. But Dual EC was self-evidently compatible with backdoors (that was, weirdly, a reason some people --- myself included! I was wrong! --- thought it couldn't be --- the tradecraft was just too clumsy). Dual EC is a PKRNG; embedded in the design is a public key for which we were expected to trust no private key was known. You can't really say that about Speck, or even Simon with its U, V, and W matrices.

Could you deliberately weaken something pretty close to a trivial ARX cipher? I'm sure you could. But NSA doesn't want arbitrary weaknesses; it wants NOBUS backdoors, where it gets cryptographic protection for its own access. It's hard to see how you'd get there with a design as simple as Simon's.

As with previous NSA cipher debates, Ashur takes NSA to task for low security margins. Why so few rounds? Why such simplistic designs? Well, that should be easy to answer: Simon and Speck are "lightweight" ciphers intended for embedded designs. They come with variants with 32-bit block sizes! This also addresses a concern I saw on this HN thread, that NSA was trying to surreptitiously replace AES with a breakable cipher. No, they're not. Even if these had been standardized, you shouldn't be using them; they have a highly specific purpose.

I think the background to this drama is mostly political. I get the sense that NSA has never really complied with the norms of academic cryptography (they're openly derisive of it). Standards groups have, in the past, given some deference to NSA's "alternative norms". That ended with Dual EC, and Simon and Speck are the first post-Dual EC ciphers where NSA is being told they're going to have to follow academic cryptography's norms. Good!

But I'd be careful reaching any conclusions past that.

Corrections welcome!

<comment><USER6> > But NSA doesn't want arbitrary weaknesses; it wants NOBUS backdoors

The NSA's handling[1] of differential cryptanalysis suggests they could consider an entire analysis technique to be (pseudo-)NOBUS. If they believed they were the only people that knew of a new cryptanalysis technique, I could see them recommending a cypher that is weak to it.

(This is only a hypothetical concern. I have not studied the specifics of Speck/Simon)

[1] Don Coppersmith, in his 1994 paper[2]: "After discussions with NSA, it was decided that disclosure of the design considerations would reveal the technique of differential cryptanalysis, a powerful technique that could be used against many ciphers. This in turn would weaken the competitive advantage the United States enjoyed over other countries in the field of cryptography."

[2] (pdf) [http://simson.net/ref/1994/coppersmith94.pdf](http://simson.net/ref/1994/coppersmith94.pdf)

<comment><USER5> This argument doesn't work. The NSA is pretty universally believed to have optimized the DES s-boxes for resistance to differential cryptanalysis. Obviously, at the time differential was a NOBUS _weakness_ \--- NSA would have deployed it against _competing_ cipher designs, which is sort of the whole point of employing cryptanalysts in the first place --- but it was never a NOBUS _backdoor_ in NSA's own design.

<comment><USER7> Wasn't that a past NSA under different leadership? Today's NSA may behave differently.

<comment><USER5> It's not my argument that we should trust NSA. We shouldn't. It's that differential cryptanalysis isn't an example of how NSA would backdoor a cipher design, and that the nature of a NOBUS backdoor is more complex than "a weakness only the NSA knows about". Dual EC doesn't have a "weakness" so much as it has a cryptographically secure access mechanism.

<comment><USER7> If I were to place a bet I'd bet that Speck in particular is fine. It's so damn simple there is just no place to put a lever. But... it would not be a very large bet. :)

</comment></comment></comment></comment></comment></comment><comment><USER8> From the email:

"So I think that as a first step, no-encryption is better than using Speck."

Thats a damned near heretical position to take as a cryptographer, but Tomer did his homework and has done nothing less than nailed his 95 theses to the door of the church of the NSA. ISO is passing on Speck for a very good reason: The NSA still believes it can cash its unapproachable arrogance with Speck in a shroud of paternal intellectualism that Edward Snowden ripped the mask off years ago. The NSA forgets itself. The ISO WG2 is headed by no less than Berenstein and Paillier. They are not the fucking peanut gallery to be fecklessly dismissed with bureaucratic elucidations such as "i will not answer that question."

<comment><USER9> I'm normally not the type to embark on wild conspiracy theories, but in this case I don't think the NSA actually believed it could push Speck into the ISO. The way Tomer depicts it, it sounds as if they almost wanted the process to fail; they made it a point to behave especially shadily.

Perhaps, and here begins my wildy unfounded speculation, perhaps Speck was an attempt at setting a carefully crafted example of how the NSA pushes a compromised algorithm in an attempt to lower the expectations of shady NSA operations - thus making their next, real attempt more credible.

But who knows.

<comment><USER7> Possible but unlikely. Bureaucracies generally aren't that subtile.

It is a good idea to be paranoid in crypto though. If I thought my adversary would be a nation state or anything else so powerful I would take a defense in depth approach of layering multiple independently developed systems using different algorithms and constructions.

</comment></comment></comment><comment><USER10> Can someone point me to a concrete use case for speck? As far as I understand, Speck is designed to use less resources than AES. However, even on very constrained devices I believe one needs at worst hundreds of kB of RAM and even a low end micro controller should be able to deliver 1 kb/s encrypted bandwith. So I have a hard time to think of any application were a chip that is designed now does not have enough power to encrypt using AES, but has a need for somewhat high bandwidth communication.

<comment><USER11> AES is _extremely_ slow when implemented in software. Many mobile and embedded processors do not have AES hardware acceleration. With hardware acceleration, AES becomes crazy fast, but that's because hard silicon can do crazy things.

However, Speck does not have a user-case, as there are sensible options available. If you don't have AES hardware acceleration, ChaCha20 can get very close in software, which is one of the primary reasons ChaCha20Poly1305 is being adopted as a common TLS cipher suite. Cloudflare has some nice benchmarks on it.

<comment><USER12> The linked mail talks about XTS constructions, so the thread is about block encryption commonly used in disk encryption schemes. They also mention that they'd have to handroll such a scheme with ChaCha. I assume that Speck offers a native wide block mode which would make a better candidate for software disk encryption if it weren't for the backdoor concerns.

<comment><USER11> That is fair, but that is by no means an argument for Speck, but instead just an argument for a block mode cipher.

What they would need to do would be to find a different sensible block mode cipher, rolling a cipher-text stealing operation mode like XTS for a stream cipher (which is not that complicated, although one should do their homework first), or using a construct to convert a stream cipher to a block mode cipher so it can use XTS directly (which is possible, but care must be taken).

#2 would probably be best. I am not sure if it a trend, but I seem to mostly see new stream ciphers popping up, so this solution is likely more sensible.

<comment><USER13> We have a stream cipher based proposal, but it's a much bigger change and needs much more review, so it can't be landed for P. A drop-in replacement for AES is a much simpler change to make.

</comment></comment></comment></comment></comment><comment><USER14> Just the heritage and reputation of the NSA in such matters should be enough to avoid using NSA ciphers.

You don't go back to a restaurant if you see someone spitting on your food.

<comment><USER15> Unfortunately, the NSA also happens to be the single largest, best-funded collection of cryptographers in the world (probably - who knows how big 3PLA/4PLA are), and do have a history of mostly-beneficial relationships with the crypto community. If you ignore NSA ciphers, you may just be trading vulnerability to the NSA for vulnerability to everyone.

<comment><USER16> Really? Name one NSA cipher that is better than an equivalent academic- designed cipher? DES? SHA2?

<comment><USER17> You get original DES, I get DES with the NSA-designed S-boxes. Want to make a bet about whose messages get cracked first?

<comment><USER18> By the NSA?

<comment><USER17> By anyone, but if adversary was NSA at the time of adoption of their suggested S-boxes then I still win.

</comment></comment></comment></comment></comment></comment><comment><USER19> It seems to me that the NSA has someone who came up with this cipher, didn't justify it very well, and then pushed hard for it. The NSA's reputation is so bad that this just won't fly, and unless they justify themselves then they just won't get a look in.

Which is fine really, because it's no different to anyone else proposing a cipher to the ISO committee. In this case, the issue could well be that the NSA tried to use it's preexisting muscle to shove through their standard without a proper design and rationale document.

Of course, it could also be the case that they deliberately weakened their own cipher. Either way, it's not a good look.

</comment><comment><USER20> There's some missing context if you read just Dr. Ashur's email and not the rest of the thread. The reason I added Speck to the Linux kernel's crypto API is unrelated to the proposed/rejected ISO standard, but rather because Speck128-XTS is being considered for disk/file encryption on low-end Android devices. This is a very important use case which has, regrettably, received much less attention than it deserves. Currently the only options allowed to Android vendors are AES-CBC-ESSIV and AES-XTS, which are much too slow on low- end processors, especially when AES instructions (ARM CE) are absent. Therefore, currently encryption isn't mandatory until 50+ MB/s AES performance. This disproportionately penalizes people who can't afford the higher end devices, who end up with no encryption. This is wrong: encryption should be for everyone.

Some have argued this problem will go away with new CPUs that can do AES faster. This is probably the "right" solution. But in practice this will require ARM CE (AES instructions). Unfortunately, this is an optional processor extension and it will be _at least_ several years before all relevant processors have it, if they ever all do. Note that this requires moving the whole industry, including not just device vendors but also the SoC and processor vendors they rely on; and devices are usually planned years in advance, with price, performance, and power efficiency being the main concerns, rather than encryption. So, it is tough and very slow, and a software solution could be in place much sooner. Plus, in any case it would be valuable to have an efficient cipher in software, in case a weakness is found in AES.

Why Speck128-XTS? Well, after extensive research it actually seems to be the best option from a technical perspective, considering many security and performance aspects; see e.g. [https://www.spinics.net/lists/linux- crypto/msg33000.html](https://www.spinics.net/lists/linux- crypto/msg33000.html) for details. Again, this is specifically for the disk/file encryption use case on processors without AES instructions. The fact that there isn't a less controversial option is really a consequence of the current state of the art, and not (as far as I can tell) just because we haven't done our homework. Most critically, in the disk/file encryption use case there is no space to store a nonce; thus, stream ciphers such as ChaCha20 are inappropriate, as IVs are reused when data is overwritten, and with flash storage and/or f2fs an attacker may even be able to recover from the "disk" multiple versions of data written to a particular logical block offset, even after only a single point-in-time offline compromise. Stream ciphers fail much more catastrophically than XTS here. (It's unfortunate how many "crypto people" seem to be unfamiliar with the problems and constraints of practical disk encryption.)

Of course, even with kernel support available, no Android device will actually use Speck until it is actually added to the CDD. That may or may not actually happen, and isn't my call. Given the increased level of controversy, it may very well be punted on for this year's Android release. Still, the alternative of no encryption is not okay, so in parallel we've also designed a new length- preserving encryption construction ("HPolyC") based on XChaCha and Poly1305, which will be published soon. Hopefully the wider crypto community will also step up to help review this construction and even publish other new software- optimized disk encryption algorithms, which are greatly needed. (And separately, perhaps the Speck team can better rise to the occasion of the, arguably disproportional but perhaps well-deserved, level of scrutity they are receiving and really set the gold standard for crypto proposals. Although I still find their latest paper to be of higher quality than you find from other designers, it evidently still has room for improvement; and crypto needs to be held to exceptionally high standards in any case.)

</comment><comment><USER13> The headline should be "Ashur advocates that it is better that a device be unencrypted, than encrypted with Speck". Ashur argues for that position and you can read his reasoning in detail in the above link, but that's the question you want to be thinking about when thinking about this.

</comment><comment><USER21> Fool me once, same on you. Fool me twice ...

<comment><USER22> I know this one - that's a replay attack, right?

</comment></comment><comment><USER23> Why are they changing?

<comment><USER24> Because Speck is said to be more performant than AES.This is discussed in the mail.

<comment><USER4> Why not use ChaCha20? I believe it's twice as fast, at least in software.

<comment><USER25> Because ChaCha20's block migh not even fit into memory on platforms that is Speck/Simon meant for. The question should be: Why not use XTEA or RC5/6.

And the answer (ignoring the NSA and it's opaqueness) is that Speck (in its reference implementation form) is slightly faster than both XTEA and RC5 and can be trivially implemented such that it is twice as fast and also uses 64b words in 128b block size variants which on typical 64b platforms leads to another essentially free 2x speedup. (Not that it makes sense to use Speck for bulk encryption on typical 64b CPU)

On the other hand team related to DJB published algorithm called Gimli ([https://gimli.cr.yp.to/](https://gimli.cr.yp.to/)) whis is essentially narrower ChaCha 20 transformation with intentionally slow diffusion as to fit onto registers of register-constrained CPUs (like Thumb) that is intended as Keccak-style sponge permutation. On the other hand in my opinion authors' paper and slides also have similar issue as what part of the original article criticizes NSA for, the security arguments for Gimli are considerably better than NSA's arguably non-existent ones but then the bigest issue I intuitively have with Speck is slow (and somewhat one-way) diffussion of the key schedule and Gimli's 4-round function is somewhat similar or even worse in this manner (although it does not have the "onewayness", for lack of a better word).

<comment><USER13> We need a drop-in replacement for AES, and Gimli doesn't have a 128-bit block size.

</comment></comment></comment></comment></comment><comment><USER26> It seems like everyone wants a set of keys to the world.

</comment><comment><USER27> >So I think that as a first step, no-encryption is better than using Speck

Yeah so the guy just throws everything out of the window.

<comment><USER28> He is only throwing out Speck and saying it is worse than no-encryption.

<comment><USER27> He's throwing out all of his reputation with that claim also.

He should not hold any Senior Researcher positions if this message is anything to go by.

<comment><USER15> Could you please address and refute his reasoning (probided in the prior paragraph), so as to encourage discussion?

<comment><USER29> Oh there are so many reasons. The easiest is the adoption problem, the same as hit HTTPS: at least 40% of top websites are still unencrypted even after a massive push from browsers to muscle them into submission; compare to the fact that with no massive push 90% of the ones that do support HTTPS don't support SSL (they only support TLS, the old standard having severe security flaws). In other words there are concrete numbers to back up the point that when an algorithm is learned to be broken, it is easy to convince panicking folks to upgrade it. But when it simply doesn't exist and hasn't ever, it is harder to convince folks that they need it.

Even more to the point, attacks do not exist in isolation and there is no "secure/insecure" dichotomy. You can see this with AES where the AES-256 key schedule is much weaker than the AES-192 key schedule, but the place where this really shines is in related-key attacks, where AES-192 has about twice the bit-strength of AES-256. Does that mean you should switch over? Well, probably not: related key attacks are structurally harder to pull off.

The qualitative differences make comparison hard. Probably if the NSA had an exploit for Speck for example, it would take the form of "steal the device running Speck for an hour to get some carefully chosen challenge-response pairs, return it back to the user, budget a day or two of time on the supercomputer to look for patterns in that data, and finally you can recover the key." (I say this in part because it's hard to hide backdoors in symmetric crypto.) Many applications would be more secure than nothing if that were the only applicable threat model.

But even quantitatively, in theory security is not a binary. It's much closer to a dollar amount: here is how much it costs to launch attacks against this system. And $0 on this scale is certainly lower than a serious vulnerability at the $100,000 level.

Basically this is a solid argument why you should not roll your own crypto but those arguments are categorically not transferable to crypto whose specifications are known openly and subjects of active cryptanalysis.

<comment><USER30> _the ones that do support HTTPS don't support SSL (they only support TLS, the old standard having severe security flaws)_

Isn't TLS the successor to SSL?

<comment><USER31> Yes, but I think your parent's point is that the sites which enable HTTPS _did_ choose to remove support for known-broken protocols versions, so you've got on the one hand people who cared at all, all doing something vaguely modern and secure, and people who did nothing (plain HTTP), with no security.

You can think of TLS 1.0 as essentially SSLv3.1, with TLS 1.1 and TLS 1.2 then as SSLv3.2 and SSLv3.3

And you might think of this as the normal course of any versioned system - tinnier and tinnier changes, except TLS 1.3 (now awaiting publication) is basically completely fresh, it only looks similar on the wire until encryption switches on, in order to maximise compatibility with legacy middleboxes, once it penetrates the middleboxes it's nothing like SSLv3.

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> So just after ISO rejected Simon and Speck, NIST is announcing new crypto competition just for algorithms like Simon and Speck, how convenient for the NSA, lets see how it goes, maybe this time they will be able to shove it just like DUAL_EC:

"NIST Issues First Call for 'Lightweight Cryptography' to Protect Small Electronics"

[https://www.nist.gov/news-events/news/2018/04/nist-issues- fi...](https://www.nist.gov/news-events/news/2018/04/nist-issues-first-call- lightweight-cryptography-protect-small-electronics)

<comment><USER5> Since it's unlikely that Simon and Speck will win this competition, given that there are other credible lightweight designs which will probably be better- analyzed since they're open, it's hard for me to see this as anything but a good thing.</comment></comment>


Badger: A fast key-value store written purely in Golang (2017) - <AUTHOR> https://blog.dgraph.io/post/badger/ <comment><USER2> (Author of Badger here)

First of all, thanks to the growing Go community for using Badger. Within a short period of time since the original announcement [-1], Badger has become very popular.

A lot has changed since the original post. Despite being tagged as a non-goal at the time of release, Badger now runs concurrent ACID transactions providing serializable snapshot isolation guarantees.

In fact, Badger is being used to serve Petabytes of data (yes, PB, not TB). On my long TODO list to write a blog post about it. It has stood the test of time, being directly used by the community and Dgraph [0]. We have put it through many different crash testing scenarios, including ALICE[1], and run Jepsen style bank transaction tests every night for 8h [2].

There're some common questions around benchmarks on our blog posts. They were done before Badger had transactions and are somewhat old by now. But, Badger's read-write performance is still spectacular. In terms of write throughput, it outperforms RocksDB (called from Go), LevelDB BoltDB, and in terms of read performance, it goes neck-to-neck against B+ tree based DBs, which typically perform better than LSM trees. Recently, there was a benchmark by Ethereum 2.0 folks, which I ran [3]. You can see the ASCIInema here [4].

There's an open bounty of $1337 on Badger to help us find scenarios where Badger could lose data [5]. So, if you got ideas, throw them in!

Thanks again for using Badger!

[-1]: Well, the original link here on HN [0]: [https://dgraph.io](https://dgraph.io) [1]: [https://blog.dgraph.io/post/alice/](https://blog.dgraph.io/post/alice/) [2]: [https://github.com/dgraph- io/badger/commit/c10276c9d3b0c4274...](https://github.com/dgraph- io/badger/commit/c10276c9d3b0c42744ed41b9177f4a9f021d8e08#diff-a3128b018385dad1c7c20cb322b8267b) [3]: [https://github.com/rawfalafel/db- benchmarks/pull/1](https://github.com/rawfalafel/db-benchmarks/pull/1) [4]: [https://asciinema.org/a/Qgyf8C50YRbtH7WpixSaBKDUQ](https://asciinema.org/a/Qgyf8C50YRbtH7WpixSaBKDUQ) [5]: [https://github.com/dgraph- io/badger/issues/601](https://github.com/dgraph-io/badger/issues/601)

</comment><comment><USER3> I've read the WisKey paper.

1\. Wasn't it simpler to just store the Key/Pointer(Offset) in RocksDB and put the values in the value log? Then the whole database just becomes a simple wrapper on top of RockDB(or whatever K/V database) with bunch of files as value log.

2\. Why 16 bytes for value pointer? 8 bytes is sufficient.

3\. If LSM size is around 5GB, screw LSM. I would rather use a simple immutable HashTable which gives you consistent snapshot out of the box for persisting to disk. Every 15 minutes launch a thread to serialize the index to disk.

Am I missing something or there is some more detail missing? I mean the reasoning to write a whole database from scratch isn't convincing.

<comment><USER4> 1\. They start off with why they don't want to use Cgo. Not a go expert, so I don't have an opinion on whether that makes sense or not. If the goal is to not use Cgo, they can't use RocksDB.

2\. It appears to be 12 bytes. ID, length, offset, all as 4 byte uint32 values: [https://github.com/dgraph- io/badger/blob/5242a997f5101ee00c4...](https://github.com/dgraph- io/badger/blob/5242a997f5101ee00c433d5fc96432ec8f111ef5/structs.go#L12)

<comment><USER3> Then any other database written in pure Go would be sufficient to keep the index.

<comment><USER4> Sure. Searching a bit, they did benchmark against BoltDB, but didn't try what you're suggesting. The benchmark I found is also prior to them adding transactions to Badger.

Edit: Actually, the benchmarks turn off sync writes, which makes them silly to me. If you're okay with losing data, you probably wouldn't have chosen a disk based kv store. [https://github.com/dgraph-io/badger-bench/blob/master/rw- ben...](https://github.com/dgraph-io/badger-bench/blob/master/rw- bench/bench.go#L76)

The default install has sync writes turned on, so why benchmark it differently?

<comment><USER2> As mentioned in my top comment, we have run benchmarks again. SyncWrites on or off, Badger outperforms BoltDB. There's a nice ASCIIrema link that you can see, which is a recording of me running Ethereum 2.0 store benchmarks.

</comment></comment></comment></comment></comment><comment><USER5> Have personally made contributions to the project once or twice. I think its a fairly young project so far being used part of bigger graph database. I went back to BoltDB for it's stability and decent performance. I think everybody has his own scale for measuring fast vs stable. It was fast but not stable enough for my scale.

<comment><USER2> Based on the commit you made, looks like there was a build breakage on a 32-bit system. We've resolved all known issues with 32-bit systems. Let us know if you encounter more.

</comment></comment><comment><USER6> Can someone clarify for me what is the use case of these key-value stores getting posted around HN recently?

<comment><USER4> They are often used as the base storage layer for more complex things.

CockroachDB has RocksDB at the bottom: [https://www.cockroachlabs.com/docs/stable/architecture/stora...](https://www.cockroachlabs.com/docs/stable/architecture/storage- layer.html)

Etcd uses a fork of BoltDB: [https://github.com/etcd- io/bbolt](https://github.com/etcd-io/bbolt)

<comment><USER7> Indeed uses an LSM tree based key value store for its data about job postings: [https://engineering.indeedblog.com/blog/2013/10/serving- over...](https://engineering.indeedblog.com/blog/2013/10/serving- over-1-billion-documents-per-day-with-docstore-v2/)

</comment></comment></comment><comment><USER8> Is it possible to make Badger completely in-memory? I.e., disable persistence.

<comment><USER9> You might as well use a simple hash-table then.

It seems that most of the design effort of this project was focused on fast disk access.

<comment><USER10> Fast disk access on linux means async io+direct io, which badger does not use.

Files are essentially mmap'd.

Regarding the hash table suggestion, you would lose compression/compaction and indexing/prefix scans.

<comment><USER2> Mmaping is optional. Badger doesn't require it, it gives you that option. Async IO in Go has been debated vigorously over the years, but there're little benefits in building that library. Because Goroutines do an equivalent job. Which is what we're doing, random reads (for value log access) spread over many goroutines.

<comment><USER10> My bad, I just glanced at the code. Are you using O_DIRECT?

Goroutines do an equivalent job but write is synchronous and thus blocks one thread of the go scheduler, as far as I can tell.

Also the benefit of the async io API is that it allows sending multiple requests in ones call. Syscalls in go do have an overhead which can be mitigated this way, I guess.

</comment></comment></comment></comment></comment><comment><USER11> Would definitely like to see the GC writeup. Are there patterns where replacing or expanding values use lots of storage or where things slow down waiting for GC?

<comment><USER2> Lack of value log GC won't affect performance directly, but every write would write to the value log GC, hence increasing its size. So, a GC is needed to deal with the growing size.</comment></comment>


Ask HN: Why people asking for chronological order feed on Instagram? - <AUTHOR> <comment><USER2> If the solution to a problem isn't perceived as being good enough (eg people think an algorithm is hiding things they want to see instead of showing things things they want to see) users will often state they want the simplest possible alternative. In the case of a timeline that's everything in the default time series order. Essentially they're saying "The algorithm isn't working, so remove the algorithm and show me everything."

<comment><AUTHOR> Does the algorithmic feed is more useful than the chronological approach? Will people move to a new app if the app provides chronological order feed?

<comment><USER2> The problem with the chronological feed is that you get people's posts bunched together. If a friend is having a night out and posting lots of selfies, meal pics, drinks pics, etc then that's all you'll see when you log in. It'd just be one person's updates for pages on end. That's a bad provably experience that stops people coming back to the app. The algorithm tries to improve _that_.

Also, and I don't know about Instagram, but on Facebook if you have 250 friends you could be seeing as many as 1000 posts a day from your network. You'd never see anything more than an hour old if it was chronological - imagine all the stuff you'd miss any time you didn't choose to scroll back.

Chronological ordering is awful.

<comment><AUTHOR> Thanks a lot. Thank you for clarifying my doubts :)</comment></comment></comment></comment>


'Smart' Pill Bottles Aren't Enough to Help the Medicine Go Down - <AUTHOR> http://www.npr.org/sections/health-shots/2017/08/22/538153337/smart-pill-bottles-arent-enough-to-help-the-medicine-go-down <comment><USER2> > Any medication can have negative side effects and some cost a lot

We see similar rates of "non compliance" in countries with free or low cost medication.

We see similar rates of non compliance for severe life threatening conditions (many transplanted organs fail because people don't take the meds) and for less severe conditions.</comment>


What's really going on with the Old Spice numbers? - <AUTHOR> http://mohrslaws.blogspot.com/2010/07/this-is-why-nobody-takes-you-seriously.html

<comment><USER2> I love meta-journalism; this stuff about investigating the investigators is good for improving one's research and critical thinking. NPR's "On The Media" does a similar thing on a weekly basis.</comment>


WebAssembly a Real-World Use Case - <AUTHOR> https://www.ebayinc.com/stories/blogs/tech/webassembly-at-ebay-a-real-world-use-case/ <comment><USER2> "the JavaScript implementation that we tried earlier performed only at 1 FPS for the vast majority. So for sure, WebAssembly is faster (50x)"</comment>


How To Upgrade Your Website Visitors To Internet Explorer 11 - <AUTHOR> http://mattjquinn.com/2013/03/15/upgrade-visitors-ie11.html

<comment><USER2> _As of this writing, Internet Explorer 11 is code-named Chrome and is being mirrored for download by Google at[http://www.google.com/intl/en/chrome/business/browser/](http://www.google.com/intl/en/chrome/business/browser/). _

Can't tell if the OP actually believes this or if the whole article is just a troll.

<comment><USER3> Its an elaborate instruction on how to trick users into downloading Chrome and making all the UI, installation dialogs, etc., make it look like it should be IE 11 (presumably, only until the point where you actually get Chrome open), including installing IE 11 icons, written in a way to trick the person _following_ the instructions (but only if that person is exceptionally trusting) into thinking that they are actually getting the users that hit their site to upgrade to IE 11.

I'm guessing that the OP knows _exactly_ what they are doing.</comment></comment>


How do you find the GPS coordinates of your photos? - <AUTHOR> http://www.pic2map.com <comment><USER2> The information will be in the exif data of the image. There are various tools to do this if you search for exif. Here is some information doing it using c# [http://stackoverflow.com/questions/58649/how-to-get-the- exif...](http://stackoverflow.com/questions/58649/how-to-get-the-exif-data- from-a-file-using-c-sharp)</comment>


Show HN: Futurecam, an advanced iPhone camera app for photography enthusiasts - <AUTHOR> http://futurecam.app <comment><AUTHOR> Hey guys, I want to show you Futurecam (futurecam.app), a labor of love, which I've been working on for the past 3 years after I quit my job at Google.

I've been been interested in photography for a long time, first with my Sony mirrorless camera. Like everyone else, I moved to smartphones but found them lacking for the kind of photography I wanted to do. I looked around, and there were some good apps, but none did exactly what I wanted. I kept experimenting with computational photography algorithms, running an experiment one weekend with a billion pixels, for example. I built Futurecam from this exploration, and did fun things along the way like GPU-accelerating and optimising our algorithms to process 1GB of data every second on an iPhone!

I built Futurecam not to be a replica of an SLR in software form, but to do things an SLR cannot do. For example, Futurecam's Liquid Shutter lets you change the shutter speed of a long exposure after capture. You can play with this live on our web site futurecam.app. Futurecam also has a light trail video which, again, you can try out on the website. And more.

Try it out for free, and if you know anyone passionate about photography, let them know.</comment>


ZenPen ~ Minimal Distraction, Maximim Zen - <AUTHOR> http://www.zenpen.io/ <comment><USER2> ZenPen is great, but there's one thing I'm missing though. What I'd really like to see is a focus mode like in iA Writer. For those who don't know iA Writer's focus mode, it basically just makes the current sentence stand out more by reducing the contrast of the other sentences. So that looks like this: [http://imagr.eu/up/52bab340db21e_Capture_d%E2%80%99%C3%A9cra...](http://imagr.eu/up/52bab340db21e_Capture_d%E2%80%99%C3%A9cran_2013-12-25_%C3%A0_11.27.47.png)</comment>


Is it fair for Linode to do so? - <AUTHOR> http://i.imgur.com/LGGEyX1.png

<comment><USER2> Do you really need referrals for your server to live?

It does seem innocent, though I didn't see anything about where you posted it yourself.

It may not be like having your AWS key stolen because you accidentally committed to github, but when you toss something out to the public that can be abused and ruin your reputation-how else would they respond?

<comment><AUTHOR> No I don't really need it, that's why I found that after seven months.

This afternoon there was a networking outage in Linode Fremont impacted my website, so I clicked several links on Linode website and noticed that.

What disappointed me is that Linode can suspend referral program without notice or giving appeal while still benefiting from traffic, every day our website delivers 150K to 200K impressions of Linode logo.</comment></comment>


Pluto Is Slowly Erasing Its Face - <AUTHOR> http://motherboard.vice.com/read/how-pluto-erases-its-face

<comment><USER2> should have been 30000 mph</comment>


A statistical study of inversions (slash chords) in popular music - <AUTHOR> http://www.hooktheory.com/blog/statistical-study-inversions-slash-chords-popular-music/

<comment><USER2> Pretty in line with classical music theory. Further, one would expect that I6/4 chord which was not functionally analysed in the article will be in majority of cases followed by V chord, possibly the two chords sharing the same bass note.

<comment><USER3> Actually, in popular music I'd expect I6/4 not to resolve normally to V in a lot of cases, since that's a cadence that sounds characteristically old. I'd expect to a lot of I6/4 straight back to tonic (alternating bass line) or deceptively to vi.</comment></comment>


A kill switch to countermeasure border controls? - <AUTHOR> https://blog.vrypan.net/2017/02/22/a-kill-switch-to-countermeasure-border-controls/ <comment><USER2> They're not going to be terribly impressed if they work out you've done this. Consider whether the risk of having this discovered, the risks to you about what you'll need to say when they get suspicious about a wiped laptop, and whether the consequences of getting caught out are worse that the consequences of having CBP gain access to the data you carry across the border...

I wouldn't do this - I'd either wipe/factory-reset the laptop before travelling (and plan on downloading whatever data I need while travelling once through border control), or just take a minimal plausible setup and accept that it'll possibly get searched/imaged at the border.</comment>


Craigslist Telecommute Jobs - <AUTHOR> http://craptome.org/cl-tele/

<comment><USER2> An interesting idea, but in my experience craigslist has some of the most flaky job-listers ever. I've responded to hundreds of telecommuting design jobs, and even with a really strong portfolio and website, I get little to no responses.

</comment><comment><USER3> is there a way to sort by date?</comment>


Migrate to Python 3 Now, There's Little Time Left - <AUTHOR> https://medium.com/better-programming/why-you-must-migrate-to-python-3-now-2a2729631a22 <comment><USER2> > It's not hard to upgrade your code

People keep writing blog posts about how easy it is to migrate your code, and I just can't imagine that these people have any experience maintaining a Python2 codebase outside of toy projects or libraries.

At work I maintain a Python2 codebase that's been under development since 2016. It's huge, relies on now-deprecated Py2-only libraries that we can't realistically switch away from, full of Py2-specific syntax, and reliant on Py2's handling of Unicode strings. We scoped out what it would be like to upgrade it to Py3, and determined that we would basically need to rewrite large parts of it from scratch. This isn't an acceptable trade-off for the business in terms of development time and priorities.

Instead we are slowly breaking out the monolith's functionality into Py3 services, which is much more tightly-scoped (and more palatable for management). But realistically speaking we will be maintaining Py2 code for the foreseeable future, and I can't imagine we are the only company in this situation.

Upgrading a production codebase from Py2 to Py3 isn't easy, or even possible in some cases. And frankly, all these blog posts suggesting that migration is trivial are insulting.

<comment><USER3> 95% of the migration effort is trivial (I say this as someone who has migrated 100k+ loc myself as part of a much larger migration effort).

There's things that are tricky, don't get me wrong: unicode handling can be tricky, though six.ensure_str/bytes usually allows you to defer that problem. Futurize and 2to3 do _so much_ of the work that in my experience the majority of files can be migrated by automation, unicode warts included.

The hard stuff is when you have extension modules or weird metaprogramming stuff (there's also one particular case I had to deal with around code generation). That takes effort to migrate, but it's the long tail.

If you need to rewrite your code to enable the py3 transition, the issue isn't python, it's your coding choices, and you should rewrite your code anyway.

<comment><USER2> > If you need to rewrite your code to enable the py3 transition, the issue > isn't python, it's your coding choices, and you should rewrite your code > anyway.

I... don't even know what to make of this advice. Have you ever worked for an engineering organization with more than 5 members? I can't just go to my boss and say, "I need the next six months to rewrite our whole backend". I'd get laughed out of the room.

Without a clear, business-first reason for an engineering project of that magnitude, it's not ever going to be a priority or a realistic option.

<comment><USER3> > I... don't even know what to make of this advice. Have you ever worked for > an engineering organization with more than 5 members?

Yes.

> Without a clear, business-first reason for an engineering project of that > magnitude, it's not ever going to be a priority or a realistic option.

I'm not suggesting that there is any realistic solution. I'm simply stating that the cause of your pain isn't py2 to 3, but bad development practices that existed independent of language or migration. These were going to cause you pain at some point no matter what. It just happened that py3 was the forcing function, as opposed to something else next year.

<comment><USER2> While I won't deny that there were some unfortunate design decisions made in the codebase (some _very_ questionable choices were made at some point), I think that's inevitable in any codebase of a certain size and age that's been worked on by enough people in a company that's changed substantially a number of times.

But that's not the cause of my pain. Bad code can and will be written in Py2, Py3, or any other language. The cause of my pain is that the language developers chose to abandon work on the language that we use in favor of a different language, one that is fundamentally different in some important ways. As a result, the tooling and ecosystem on which we've built our product is slowly stagnating and is getting close to being fully disfunctional.

<comment><USER3> If you have bad code you'll eventually feel the cost of that bad code, if the code lives for any significant length of time. Something will make you feel that pain, either a new feature you need to develop or a change to the ecosystem, or something else entirely.

If not py3, then something else. Specifically, the tooling ad ecosystem isn't dysfunctional, you're just unable to maintain functionality among changing requirements. "We must use py3 for our codebase" isn't particularly different from "we must now support Japanese users" or "we need a new endpoint that allows us to view data along a new axis". All 3 changes had the potential to cause you developmental pain. You just hit one prior to the others.

</comment></comment></comment></comment></comment></comment><comment><USER4> "from python2 import {__some_old_feature__}" could go a long way toward easing the transition.

Disclaimer: I spent a lot of time converting things from python2 to python3. It's a big pain.

Pet peeve: don't break compatibility for ideological reasons. For example, the print statement didn't need to die: it could have lived on as needed side-by- side with the print() function.

<comment><USER5> I don't get that pet peeve. There are aspects of converting Python 2 to Python 3 that can be hard, but print statements are really not one of them as far as I've seen. Converting print statements to print function calls can be done mechanically. I guess it's fair to say the print statement didn't need to die, but it really didn't need to live either.

</comment></comment><comment><USER6> I don't get this. Python is open-source. Surely _volunteer_ programmers don't need the blessing of Guido to continue working on Python 2. And surely the number of people who are still using Python 2 somehow indicates that there will be some people among them capable of updating and maintaining Python 2. I don't think time is "running out" at all, at least not in a sense that is meaningful to people still using Python 2, after this many dire, repeated warnings to switch now.

<comment><USER7> There are a couple of projects focusing on continuing development of python 2, and possibly backporting python 3 feature where it makes sense. [https://github.com/naftaliharris/tauthon](https://github.com/naftaliharris/tauthon) seems to be the one with the most support.

The other problem is that it's not only your python version that won't see official upgrades, but most of the libraries you use won't either. But I guess if you're OK with Python 2 you're probably also OK with out of date versions of django and numpy or whatever else you use.

But basically, anybody who hasn't at least started their python 3 port by now have probably already weighed the pros and cons and decided that they're never going to do it, and yelling at them isn't doing anybody any good</comment></comment>


How Language Helps Erase the Tragedy of Road Deaths - <AUTHOR> http://nautil.us/blog/how-language-helps-erase-the-tragedy-of-millions-of-road-deaths <comment><USER2> > "car accident" on the grounds that it presumes that the drivers involved are > blameless—a presumption that is correct only 6 percent of the time

Uh, that is _not_ the connotation that anyone has when they hear "car accident". Otherwise it wouldn't make sense to say, "Whose fault was the car accident?"

Accident just means it wasn't intentional. I think very, very few "vehicular collisions" are intentional.

Not that it matters. This Orwellian shit _rarely_ flies with the general population, anyway. Now if you'll excuse me, I'm going to have a Rose of the Prophet Mohammed and some Freedom Fries.

<comment><USER3> I think more collisions than most would assume were intentional, unless you have easy access to guns it has to be the simplest way to commit suicide.

</comment></comment><comment><USER4> Villager: "What happened, Danny?"

PC Butterman: "Car accident"

Villager: "Nasty way to go"

Sgt Angel: "Official vocab guideline state we no longer refer to these incidents as 'accidents'. They're not 'collisions'"

PC Butterman: "Right"

PC Butterman: "Why can't we call them accidents again?"

Sgt Angel: "Because accidents imply there's no one to blame"

</comment><comment><USER5> The Traffic Safety report by DoT they refer to doesn't differentiate between people involved and drivers that caused accidents.

I'm thinking that some two-digit percent of deaths are really blameless, because it's some other vehicle crashed into them. Just for example, a young male driver was speeding and misjudged a maneuver and collided with a vehicle with a family of 4 inside.

<comment><USER6> > was speeding

You're saying that's blameless? If someone were speeding, I would blame them for the crash.

<comment><USER7> I think deepsun means the person who died was not at fault.

</comment></comment></comment><comment><USER8> So good news for self-driving car perceptions.</comment>


Show HN: QR Links – Share links from PC to smartphone - <AUTHOR> https://chrome.google.com/webstore/detail/qr-links/pmhmljldhgfhocnknempediofdbiaebd Easily open any URL in your smart phone by scanning the QR code of the URL. <comment><USER2> Look great to me. I also have a QR code app [http://www.qrunched.com](http://www.qrunched.com) have a look.

Thanks</comment>


Show HN: MPrif – Cloud App for Housekeeping Management in Hospitality Industry - <AUTHOR> https://mprif.com/ <comment><AUTHOR> Hello HN! I designed this app to let hoteliers manage their housekeeping tasks remotely on any device after I saw a lot of them still relying on word of mouth for it. By simply asking the housekeeper use the app on his/her device, the owner or the manager can automate housekeeping tasks. Reports can be delivered daily on any device and logs can be maintained per room with photos to go back in time and see why the customer complained about rooms being dirty on TripAdvisor and other review sites like Yelp.</comment>


It's Time to Ditch Facebook and Give Google+ a Try - <AUTHOR> https://lauren.vortex.com/2018/03/20/seriously-its-time-to-ditch-facebook-and-give-google-a-try <comment><USER2> wtf no.

EDIT: Let me expand on this with a question for the readers and the author of this post. This was published today, amidst the whole CA scandal. Why would the people leaving facebook amidst concerns of centralization of user data and privacy, go to Google, which its own set of as much if not more user data?

Google knows your search history, Youtube viewing habits, owns your web browser, email, photo vault, etc. If you have an Android phone it knows where you are at every moment --where you live, where you work, the places you frequent-- the apps you use, and probably a ton of other data points.

The thing they are missing from their complete data arsenal is your social information, which is worth a lot. Why would anyone leaving Facebook over concerns about big tech having to much data and power over them go hand it over to the bigger data tracking and ad business?</comment>


The Truth Is That Android Is Cheap, Not Good - <AUTHOR> http://techcrunch.com/2013/01/22/cheap-not-good/ <comment><USER2> Android is both cheap and very good. A Nexus 4 stands toe to toe with iPhone hardware and Android 4.2 is the best designed and most innovative OS in wide use.

Nexus branding makes it easy to find both good Android and good pricing (even scalper's pricing is hundreds of dollars less than an off-plan iPhone).

If the gripe is with cheap devices with trailing-edge versions of Android, both Google and the OEMs can share the blame. Google could do more to eliminate excuses OEMs have for not keeping up with the latest versions, and reward the ones that do with an expanded Nexus branding program. But consumers still have the choice of buying Nexus devices.</comment>


Landlord sues tenant after tweet about moldy apartment - <AUTHOR> http://arstechnica.com/tech-policy/news/2009/07/landlord-sues-tenant-after-tweet-about-moldy-apartment.ars <comment><USER2> Um... wow. I guess someone at that company was really bored.</comment>