Why humans learn faster than AI–for now - <AUTHOR> https://www.technologyreview.com/s/610434/why-humans-learn-faster-than-ai-for-now/ <comment><USER2> This is a very nice idea! To use the time taken to complete the game with nonsense textures as a proxy for the importance of background knowledge.

However, I can't avoid bitching a bit about how the fact that a strong prior can really boost sample efficiency is really, really old news. That is one of the main ideas in Inductive Logic Programming, where priors are specifically encoded as background knowledge, or a strong language bias, etc. It's a bit disheartening to see people reinventing the wheel instead of looking a little outside their narrow field.

<comment><USER3> Hi, I am one of the authors of the paper. Thanks for your comment! In our paper, we never make a claim that we are the first ones to show that prior information matters. The goal of our paper is to study what kinds of prior information are more critical during human gameplay. A major finding of our work is that general priors about objects which we learn when are as little as 2-3 months old are some of the most important prior knowledge that guides efficient gameplay. Unfortunately, the media articles have missed this important distinction so it appears as if we are claiming that prior knowledge matters (which in fact the field has known for a long time). Thanks again for your comment!

<comment><USER2> Hi and Thanks for replying!

I did warn I was going to be "bitching" about that bit :)

I read your paper- I agree that you didn't make any claims that you're the first to notice the effect of strong priors on sample efficiency. Like I say above, I think your paper is really interesting and that your experiments are a great idea- it's a little disappointing to see it did not get as much interest on hacker news as other recent work on deep reinforcement learning posted on here (but then, this is a popular forum, not a scholarly journal :).

One thing I felt was missing (unless I'm the one who missed it) is some examples of what happens when a human player has played the original game once, before attempting the ones with the various ablations. I tried that- I played the un-masked game once, then tried the "hard mode" game, the one with visual similarities masked, and I was able to finish it without dying, although I kept falling off platforms (I guess I got lucky and missed the fire pit). I even managed to kill the blobs. This was all done from memory, of course, but that's memory of object affordances, identities and semantics, not specific keypresses. I think that's an interesting thing to note.

But, you know- just a minor detail :)

Thanks for writing the paper and making it available on arxiv.</comment></comment></comment>


Ask HN: Want to make $500 for scraping some data? (challenge) - <AUTHOR>

Open a new tab and go to google.com. Type in a band name like: "All Time Low"
You'll notice a box on the righthand side with more info about the band.
If you click the down arrow you'll see a "People also search for" section.
If you can scrape that data, in under 4 seconds(Sorry no PhantomJS), I'll pay you 500$ for your solution. <comment><USER2> nodejs, requires node package _fetch_

Under four seconds, please note that this violates Google's ToS and you will likely be blocked if you do this on any significant scale.

      var bandname = "All Time Low";

      var fetchUrl = require("fetch").fetchUrl;
      var url = "https://www.google.de/search?q=";
      bandname = bandname.replace(" ", "+");

      fetchUrl(url+bandname, {
        headers: {
            'User-Agent' : 'Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2049.0 Safari/537.36'
        }
      }, function(error, meta, body){
        var ret = [];
        var alts = body.toString().split('alt\\x3d\\x22');
        alts.forEach(function (alt) { var cur = alt.split("\\x22")[0]; if (cur.indexOf("(")==-1)    ret.push(cur) });
        console.log(ret);
      });

<comment><AUTHOR> Worked like a charm! Whats your email!? I know. This is for an in house project. I don't plan on spamming google.

<comment><USER3> Just curious, I am unable to see what was the hard part in creating the solution to entail a bounty of $500?

</comment></comment></comment><comment><USER4> Not related search but "keyword suggession" can help you.

Here is Google XML API [http://suggestqueries.google.com/complete/search?output=tool...](http://suggestqueries.google.com/complete/search?output=toolbar&hl=en&q=hackerNews)

</comment><comment><USER5> Probably possible to do, however what's up with just using Last.fm's API?

[http://www.last.fm/api/show/artist.getSimilar](http://www.last.fm/api/show/artist.getSimilar)

<comment><AUTHOR> I am also using last.fm's API.

I'm looking at a number of api's and doing algorithms on the results

-thanks though

</comment></comment><comment><USER6> I'm sure they get their data from wikipedia, here's a start [http://en.wikipedia.org/wiki/DBpedia](http://en.wikipedia.org/wiki/DBpedia)

<comment><AUTHOR> it actually comes internally from their knowledge graph: Freebase

<comment><USER6> why not just download the rdf triples then?

[https://developers.google.com/freebase/data](https://developers.google.com/freebase/data)

<comment><AUTHOR> even with that I would not be able to recreate googles related algorithm myself. so that wouldn't get me anywhere.

</comment></comment></comment></comment><comment><USER7> why did you delete your s.o. question?

[http://webcache.googleusercontent.com/search?q=cache:LEbxw95...](http://webcache.googleusercontent.com/search?q=cache:LEbxw95yNqIJ:stackoverflow.com/questions/25336400/how- to-scrape-googles-similar-searches-challenge+&cd=1&hl=en&ct=clnk&gl=us)

<comment><AUTHOR> got 4 downvotes and no answers. figured that wasn't going to help anyone to decided to ask here instead.

</comment></comment><comment><USER8> I have a working prototype. How do you want to proceed concretely?

<comment><AUTHOR> sorry somebody beat you to it!

</comment></comment><comment><USER9> Did you try Import.io?</comment>


We're Getting Very Close To The Perfect MacBook - <AUTHOR> http://techcrunch.com/2012/11/17/13-inch-macbook-pro-review/ <comment><USER2> For me, a non-Retina 13" MacBook Pro with upgraded memory and SSD hard drive approaches the perfect machine. It's cost effective and blazingly fast. The extra cost associated with a Retina display isn't worth it to me, especially given the premium Apple charges for the SSD upgrade.

</comment><comment><USER3> would get if 15"

<comment><USER4> The first Macbook Pro w/ retina IS 15"

<comment><USER3> oh woops, thanks, my bad.</comment></comment></comment>


Kensington Security Slot - <AUTHOR> http://en.wikipedia.org/wiki/Kensington_Security_Slot <comment><USER2> Or you could just wear "iPad-Compatible Clothing"...

<http://www.scottevest.com/company/ipad.shtml>

(Scroll down and check out the picture of Woz with his iPad in his iPad- compatible jacket. Hilarious.)

</comment><comment><USER3> My tc1100 slate has this. It makes the thing _much less mobile_. No surprise there, since this is the purpose of the slot and the lock that goes in it.

However, it also interferes with the purpose of the iPad. Imagine how you'd like to use a sketchpad that was chained to the desk.

<comment><USER4> I don't think anybody is advocating keeping it chained to your desk while using it. I imagine it is more along the lines of being able to pop in a lock when you go to grab a coffee or go to the bathroom and unlocking it when you come back.

<comment><USER3> I should think that locking it in a drawer or carrying it with you are much more convenient and secure. For one thing, it isn't obviously visible.

<comment><USER5> But I so seldom have access to lockable drawers in the coffee shop.

<comment><USER3> Then you should carry it with you.

<comment><USER5> To the bathroom? Ew.

</comment></comment></comment></comment></comment></comment><comment><USER6> False sense of security? A bit of a coincidence, I've been looking at bicycle locks before this and can't help but think that the cables used in Kensington security locks could practically be cut through by a pair of scissors, let alone cutters actually made for the job!

Edit: I /really/ need glasses, ipAd not ipOd...

<comment><USER7> I once tried to cut a bike brake cable with a pair of diagonal cutters. It didn't work - and that thing is less than 1/8" in diameter (and is meant to be cut). The Kensington locks are made of thicker, strong cables and though still fairly flimsy, are going to require cable cutters to break.

In the end it's all about risk management - what's the probability that someone goes to a coffee shop specifically to steal a laptop and is armed with cable cutters? And if they have cable cutters, are they going to bother to use them to steal your laptop, or are they going to steal the laptop next to yours that's not locked up?

FWIW, I take my laptop into the bathroom with me.

<comment><USER8> It's very hard to cut the cable with standard lock cutters. There are specific cable cutters (usually used in construction) work that can cut through the cable a lot easier though.

Unfortunately, the weakest part of the locks is either the lock itself, or the slot on the laptop. My friend recently had his MBP stolen when someone just ripped out the lock from the slot (so theres presumably a huge gash in the side of it now). We're still trying to figure out how it happened, but we're pretty sure it was something like those hydraulic jaws inserted between the lock and the body of the laptop.

Really, the ideal behind the lock is to deter theft by people who want to resale the laptop after. Anyhow who is willing to use a damaged laptop, or has customers who don't care where the laptop comes from can just continue to steal stuff more or less nilly willy.

</comment></comment></comment><comment><USER9> it seems like the Kensington Security Slot is an interesting market that Kensington pretty much have a monopoly over. Does anyone know how they got to this point?

<comment><USER10> "The designer met with each of the original equipment manufacturers (OEM) and convinced each computer manufacturer to add a small, security slot in their laptop designs. Compaq was the first OEM to incorporate the Kensington security slot in 1991."

[http://uk.kensington- press.com/news/article.aspx?id=232&...](http://uk.kensington- press.com/news/article.aspx?id=232&core=E)

The also are very open with the details, not trying to charge a licensing fee or anything: <http://us.kensington.com/html/1356.html></comment></comment>


What's it like to be one of the Jeopardy clue writers? - <AUTHOR> https://tv.avclub.com/what-s-it-like-to-be-one-of-the-jeopardy-clue-writers-1798277448 <comment><USER2> > And you don't want stand-and-stares; that's the one thing we're always > trying to avoid.

This reminded me of this recent one: [https://www.youtube.com/watch?v=h33u2eeVqXo](https://www.youtube.com/watch?v=h33u2eeVqXo)

<comment><USER3> Haha, when pop-culture knowledge meets specialized "high school clique-esque" category of questions. This is kinda funny to me but I feel like it shouldn't be.

I'm nearly 100% certain all three of the contestants would run circles around me in 99 out of 100 categories but this entire group of questions made me feel like I could be a Jeopardy champion.

<comment><USER4> It's not surprising that this would happen occasionally, given that there are only 3 contestants per show. Most shows will have someone who knows football, but of course not all.

<comment><USER4> Entire category stumpers are probably somewhat but not extremely rare, but this one is going to get more media coverage but it aligns well with the narrative of "look how bad these nerds are at sports knowledge."

</comment></comment></comment></comment><comment><USER5> It was an interesting read... that I couldn't finish because the page kept crashing until my browser (Safari, iOS 11.2.5, iPhone 8) finally gave up on reloading it. Even made my phone warm up at one point.

Happens too often on Gizmodo Media Group sites (I'm on Jalopnik almost daily.)

<comment><USER6> Same. Horrible user experience for what seemed like a decent article.

However, using reader mode on iOS Safari keeps all the ads out and it then reads fine.

</comment></comment><comment><USER7> It reminds me of the role of DMs in RPGs: creating a small world in each question, category, and show for the player to interact with.

This is a trade site? It might have been interesting or helpful for readers if they'd asked about salaries in the field (not necessarily what the subject earns directly, more in general).

<comment><USER2> > This is a trade site?

If you're talking about the A/V Club, it's not a trade site; it's a pop culture review/etc. site.

</comment></comment><comment><USER8> >I have areas of knowledge—I know literature, sports, a few others—but one of the interesting things is that you're always trying to write things that are accessible, and if it's a subject you know a lot about, then there's a danger of writing things that are too esoteric. Which might happen to me with English literature. But if I'm writing physics then I can be pretty certain: If there's something I've heard of, then most people have heard of it, and so it's easier to write things that you don't know about.

I've noticed Jeopardy placed massively disproportionate emphasis on sports and the humanities compared to science, and I guess this reveals why. The writers don't know anything about that sort of thing, and so their threshold for "too esoteric" is extremely shallow for any STEM topic. Meanwhile, because they do really intimately know classical novels or football or such, they don't consider asking what team won the 1979 Superbowl or asking about a tertiary character in Crime and Punishment as being the least bit excessive. I guess there's really nothing that can be done - they even are aware of the problem but still can't seem to fix it - and it's not too big a deal regardless. I still try to catch the show every chance I can.

<comment><USER9> I suppose literature and sports are understandable to everyone. People might not know the individual fact but they understand the meaning and can at least try to remember something. In STEM, you'd get "stand-and-stare" with any technical term where the entire field is completely alien to most viewers and players.

The same effect happens in casual conversation. Arts majors have all kinds of accessible topics they like to talk about with anyone, but a programmer can't even begin to say something about stacks or garbage collection or whatever with a non-programmer. It's a totally walled off other-world for most people.

<comment><USER10> Arts majors who talk about the details of a particular pigment, or chiseling techniques will be about as well received as programmers rambling about stacks. Technical details are rarely relevant to those outside the profession.

People outside tech have lots of questions and interest in talking about tech. Product decisions are more accessible and meaningful than implementation details.

</comment></comment></comment><comment><USER11> Jeopardy is awesome, I try to watch it every night if possible. The only reason I use the TV antannae.</comment>


Quantum Random Access Memory - <AUTHOR> https://arxiv.org/abs/0708.1879 <comment><AUTHOR> I am not knowledgeable enough in Quantum Computing, but I don't see any architecture presented in this article, as the authors have said in the abstract.

Would someone kindly point me towards it?

Thanks :)</comment>


Ask HN: What if Linux and FreeBSD had the same license? - <AUTHOR> It's my understanding that Linux users are opposed to software that isn't compatible with GNU; what if Free/Net/OpenBSD and Linux all used the same license: would support and use of Linux and *BSD be the same or is there more to it than just the politics and religion of licensing? <comment><USER2> I think the vast majority of Linux users don't know, and further, don't care about the licensing differences between the GNU licences and the various n-clause BSD licences.

For those that do know and do care, I think there's very few who would refuse to use BSD-licensed software. From a GNU-perspective, the BSD/MIT-style licence is misguided, but not reprehensible.

But to the core of your question: yes -- there is more to the choice between Linux and the BSDs than licensing.

FreeBSD, perhaps most of all, is a linear descendant of the original Bell Labs Unix. And it maintains a style of development that emphasizes consistency, elegance, and a smallish core group of like minds curating the system. That style is true of all(?) the BSDs, with some different emphasis in each camp.

The Linux kernel, OTOH, was originally written by a gifted but inexperienced student, attempting to get a work-alike of Minix that took advantage of the i386's new features. It was a quick hack, put together over a few months, to get something running that proved it could be done. The kernel was paired with userland applications from the GNU project, from the general community of "source available" software at that time, and massaged into the mostly novel concept of distributions by many and varied groups of people, often with only distant relationships with the kernel developers.

Over time, the skill and experience levels of the Linux kernel developers has matured, but it maintains a (much) more broad range of skills, aptitudes, experience, goals, etc, than the BSDs.

Which is not to say that either of the Linux kernel or the BSD kernel(s) is "better". They have different strengths and weaknesses, as do their userland ecosystems.

It's all __far __more important than the licensing differences.

My view, YMMV, etc.</comment>


Ask HN: Has anybody tried LinkedIn ads? - <AUTHOR>

If so, did you find it effective? <comment><USER2> I have, and I've found them about as effective as Facebook ads albeit on a much smaller scale (impression delivery-wise).

<comment><USER3> only as effective as Facebook ads? b/c they're at least 10x the price...

</comment></comment><comment><USER4> Disclosure: Haven't tried it. Why? Too expensive, and the engagement level on the site is too low (although I have no metrics to prove it).

</comment><comment> what-to-do They need to add keyword targeting ASAP so ads could match people's keywords within profiles.

</comment><comment> what-to-do Running campaign for last week, useless so far.

<comment><AUTHOR> Can you please elaborate on why its useless?</comment></comment>


Developing for old browsers is (almost) a thing of the past - <AUTHOR> http://37signals.com/svn/posts/3097-developing-for-old-browsers-is-almost-a-thing-of-the-past

<comment><USER2> By moving to IE9 he's discounting all corporate customers who haven't moved to Windows 7 yet.

This leaves them with only one option if they want support on a long-term supported browser, which is the recently shipped Firefox Enterprise Support Release.

<comment><USER3> >>>By moving to IE9 he's discounting all corporate customers who haven't moved to Windows 7 yet.

Nonsense.

Chrome and Firefox will both run on XP.

<comment><USER2> You'll notice the second sentence there, which talks about Firefox ESR as the only option if they want a long-term supported browser. Many large corporations will not switch to a browser which updates itself more often than they can easily test it against all of their internal apps.

<comment><USER4> Those corporations tend to be a pain to work, have lots of internal crap apps, and don't use external stuff like Basecamp anyway. Good riddance.

<comment><USER5> They also have a ton of money. You might not want any of it, but some do. Continuing to support IE7/8 for that reason makes sense.

</comment></comment></comment></comment></comment><comment><USER6> I think the title is a little bit misleading. The moment you can drop support for browser versions is pretty dependent on the requirements of your client, and your visitors. 7% for users with IE8 or lower is a pretty tech-savvy crowd, many developers might not have the luxury of dropping support for IE8 because many of their visitors still use that browser.

<comment><USER7> Agreed. There's still a very significant portion of China using IE6, for example. If you've got an international focus on non-developers, it's not really even close to feasible to drop IE6-7.

</comment></comment><comment><USER8> I'm so sick of websites not even attempting to render in a browser not in their whitelist. Please give me a button that says "I understand the risks, but I want to try anyway."

<comment><USER9> We don't do that. We only discriminate against browsers we know will have problems. Like IE6-8. So what we're running is actually a blacklist.

If you show up with a browser that's not one of the big four, we're just letting you in on your own accord.

I completely agree that whitelisting for browsers is bullshit.

<comment><USER10> I think cutting IE 8 off is a little premature. I agree it's a hassle to support but I think of for example Rogers Cable, a client of mine still sitting on locked down XP across the entire office base. You just cut their 6000-ish employees off at the knees. They can't install another browser even if they wanted to, and I'm sure that same situation exists in a lot of other corporations.

<comment><USER11> The original Basecamp isn't going anywhere, so those 6000-ish employees won't be out a thing. They'll just need to advance a few IT years to be able to use Basecamp Next.

From the article:

"We know it's not always easy to upgrade your browser (or force an upgrade on a client), but we believe it's necessary to offer the best Basecamp we can possibly make. In addition, we're not going to move the requirements on Basecamp Classic, so that'll continue to work for people who are unable to use a modern browser."

</comment></comment></comment></comment><comment><USER12> The multibillion dollar organization I work for just updated to IE8 from IE6 last week. We aren't allowed to use new browsers or chrome frame for "security" reasons. ha!

<comment><USER13> Lucky you! I work at a large hospital with (likely) 10k+ computers running XP and we're still stuck on IE6.

I'm not sure what the plan to migrate away from IE6 is but my guess is that it will be a massive pain for our IT department.

I have to imagine that IE6 will continue to limp along for a number of years to come, but hopefully large organizations will have learned a lesson about depending on a specific browser version (or a specific browser for that matter).

<comment><USER14> Is Chrome Frame an option?

</comment></comment></comment><comment><USER15> My understanding is that IE has a significant market share among users with accessibiliy needs (came up in conversation after the recent jquery 2.0 browser support discussion). While that may not be important for 37 signals it's an oft overlooked side effect of dropping version 8 support.

</comment><comment><USER16> Now the problem becomes mobile browsers... (hover vs. tap, tiny resolutions, differences in form controls, sometimes crippled features that work fine in a "pc" based browser, fluid layout choices, float issues)

There will always be madness.

[edit] Took me a few to find this link again. Do compatibility charts like this look familiar? <http://www.quirksmode.org/m/css.html>

</comment><comment><USER17> IE6 may ye rest in peace... (or hell)</comment>


Melinda Gates: Corporate America must stop demanding we all be workaholics - <AUTHOR> http://www.businessinsider.com/melinda-gates-how-corporate-america-drives-away-women-2017-9 <comment><USER2> Kinda hard to take this seriously when her husband's company was a well known proponent of stack-ranking.

</comment><comment><USER3> True! Now that we are leaning towards a more automated future we need to enjoy the benefits it brings.

Job burn out is a real thing. If workers don't have a balance between work and life, it leads to mental health issues.

</comment><comment><USER4> Indeed - I'm all for doing an excellent job and making sure my work is clean, resilient, etc. but I am not going to let myself burn out like at my last job.

</comment><comment><USER5> Thanks for the insight, Melinda.

I really needed it, considering my former Microsoft manager personally laid me off because he just didn't like me.</comment>


South Korean students flock to Japan - <AUTHOR> https://www.japantimes.co.jp/news/2019/05/13/national/south-korean-students-flock-japan-birthrate-sinks-unemployment-climbs/ <comment><USER2> This article is laughably wrong (probably a puff piece to entice Korean students to work in Japan). The truth is exactly the opposite: there are fewer Koreans in Japan every year (as measured by foreign residents in Japan -- this includes work and student visas). The fastest rising immigrants to Japan from 2015-2018 are in descending order[1]:

Vietnam Cambodia Uzbekistan Myanmar Sri Lanka

South Korea comes in dead last, having DECLINED by 10% during the same period.

The truth is that as soon as Korea became a developed country, having joined the OECD in the 90s, immigration to Japan slowed to a trickle, precisely for the historical reasons that you might suspect.

[1] [https://en.wikipedia.org/wiki/Demographics_of_Japan#Foreign_...](https://en.wikipedia.org/wiki/Demographics_of_Japan#Foreign_residents)

<comment><USER3> It did sound like a puff piece, since the only company that was even mentioned by name was a recruiting/staffing agency.

</comment></comment><comment><USER4> South Korean here. My anecdata: some of my friends went to Japan for advanced degrees. Most of them came back within a couple of years after their study.

10x or more people around me went to US. The majority of them are still in the country after a few years.

Such tendency was remarkable to me, given the difficulty of learning English and relative ease of learning Japanese by Koreans.

There is one thing I can't understand from the article: it says a low birth rate as a reason of an increase in migration. Why would a low birth rate lead to more migration? I can understand the unemployment rate as a reason, and SK surely has a serious problem of low birth rate.. but that's for new babies...

<comment><USER5> > given the difficulty of learning English and relative ease of learning > Japanese by Koreans

This surprises me a bit (I believe you; I am just surprised.)

Why do Koreans think learning Japanese is easier than learning English?

<comment><USER4> Syntax-wise, Koreans and Japanese are very close. The sound systems are also close (e.g. no p/f v/b distinction). Kanji and Hanja are just Japanese/Korean versions of Chinese. Some words are shared and some nursery rhymes have the same melody. They even memorize the multiplication table with the same melody. In many ways, their languages and cultures have evolved with proximity for a long time, like thousands of years.

English and Korean are just two languages that would have almost no way of influencing each other directly for a long long time. They evolved independently, and once one is familiar with one language system, learning the other is just... painfully difficult in my experience.

If you see grammar errors in my comment, a Japanese person would very likely show similar mistakes in their English writings.

<comment><USER6> Interestingly enough, I feel that your grammar is pretty much spot on perfect, at least from this excerpt. It's the cadence and rhythm of the way you write and format your sentences that subtly suggest you're not a native English speaker.

Maybe the thing that most sticks out to me is saying "English writings." I don't think a native speaker would say writings, just "in their English", or perhaps "In their written English."

Your English is fantastic, this is me simply musing on what you're suggesting.

<comment><USER4> Thank you, you made my day. I spent way too much time reading commets in HN, and that effort paid off. :)

<comment><USER6> Of course! Coming from someone who's tried (and failed) to learn a bit of Mandarin, even the spoken language was quite tough. Chinese/Japanese/Korean -> English/Romance languages is quite a tough lingual gap to bridge, and you should be proud of yourself for achieving fluency!

</comment></comment></comment></comment></comment></comment><comment><USER7> Read the story but they're very short on the data. cited a job fair in Nagoya which had 40 Koreans. Then a Korean job search firm that placed the most people to work in Japan out of any country. Is it just me or is the article short on enough evidence to make this a piece?

</comment><comment><USER8> I don't get the "as birthrate sinks and unemployment climbs". It's not like Japan is doing well there.

And Japan is infamous for its incredibly negative attitude towards Koreans...

<comment><USER9> Have to admit I am clueless about the history between these two. Why don't they like each other?

<comment><USER10> Japan invaded the Korean peninsula as well as a sizeable portion of China and enacted horribly cruel war crimes against the citizens of those places. I won't get into details, but this comment would be akin to asking "What's the history between the Germans and Jews? Why don't they like each other?". The primary difference being that Germany had a reckoning with the history of what happened during that time, while the Japanese Government has mostly denied that any of its war crimes even happened which never allowed tensions to drop as much as they may have in Europe.

<comment><USER11> Actually, Japan has apologized repeatedly: [https://en.wikipedia.org/wiki/List_of_war_apology_statements...](https://en.wikipedia.org/wiki/List_of_war_apology_statements_issued_by_Japan)

However, Japan has more than its fair share of far-right fruitcakes who deny everything, and in both Korea and China politicians have found Japan to be a convenient whipping boy whenever they need a distraction from domestic problems.

<comment><USER12> Japan demands the issue to be "settled" or "forgotten" after mulling quick apologies. Imagine Germany demanding that the Holocaust be forgotten.

<comment><USER11> Japan and South Korea signed an agreement in 1965 that was supposed to settle all financial claims.

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

<comment><USER12> This agreement is about property claims, not about war crimes against civilians.

<comment><USER11> The agreement is about "property _and_ claims" between the two states. Of course, individuals can and have sued various Japanese entities, some successfully.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> According to some sources (Bloomberg) South Korea is currently the most innovative country in the world, and having spent significant time there, I wholeheartedly agree.

Despite the mythos surrounding Japan espoused by some ill-informed westerners, while it is a beautiful country, there is no benefit in moving from Korea to Japan. Japan, while it's my current home, is well past its heyday.

This isn't to say it won't return, but the current climate speaks otherwise.

This is a pure fluff piece.

</comment><comment><USER14> "They have experienced military service and are disciplined," said an official at a manufacturer in Aichi Prefecture. "They are good to work with, because they respect their superiors and are diligent."

<comment><USER15> Similar phenomenon in Silicon Valley with Israeli engineers.

<comment><USER16> I find israelis pleasant to work with, mostly because i think they are smart, and they have a good idea what they are doing. They also want to improve constantly.

Also they speak their mind, no bs. We need more people with this mindset.</comment></comment></comment>


Bitbucket is Down - <AUTHOR> http://status.bitbucket.org/

<comment><USER2> yup: <https://news.ycombinator.com/item?id=5558893>

Come there in desperation with us :p</comment>


Exotic, gigantic molecules fit inside each other like Russian nesting dolls - <AUTHOR> http://news.uchicago.edu/article/2015/01/22/exotic-gigantic-molecules-fit-inside-each-other-russian-nesting-dolls

<comment><USER2> We changed the URL from [http://phys.org/news/2015-01-exotic-giantic- molecules-russia...](http://phys.org/news/2015-01-exotic-giantic-molecules- russian-dolls.html), which refers to this announcement.</comment>


Why is 37Signals always the counter-example? - <AUTHOR> http://ambershah.posterous.com/why-is-37signals-always-the-counter-example <comment><USER3> It's their narrative for getting attention. That is all.

Someone once mentioned how it was clever they (tiny, unknown little company) always pit themselves against well known things (Microsoft, Apple, VC X) to try and become more legitimate over time.

<comment><USER4> They also claim that they don't want to grow. That every business has a 'natural' size. That somehow that's better than being massive - <USER2> challenging the conventional wisdom that more profit = better. They are masters of PR to geeks. Their business model pretty much relies on them doing constant PR to pit themselves as the hip small but hugely knowledgeable 'startup'.

Even the back cover of Rework reads like a parody of 37signals other stuff.

<comment><USER5> Why is that a problem?

Handful of guys doing what they like. Earning enough to pay for a modest lifestyle and I bet they get to put something away for old age.

Why does earning a living have to be an unpleasant and stressful experience?

By writing and talking about how awesome cool their careers are, they get to boost their sales. Hell, I think I might start writing about how awesome my life is.

<comment><USER4> There's absolutely nothing wrong with it at all. There are millions of small businesses doing exactly that. There always have been. Most of them just quietly get on with it and make profit.

For me, 37signals don't say anything new or very interesting. They just say it _really_ loudly, and try to make out that they're doing something radically different - when in fact they're not.

<comment><USER6> Yes, but...

37signals is not doing anything new. Tons of small-businesses have been operating on the same principles for eons. However, there is so much hype and misinformation in the e-business arena that this sort of otherwise brain-dead obvious business advice is in the minority, and stands out all the more. There isn't _one_ single way for businesses to find success, online or off, but if web entrepreneurs followed 37signals advice more often than they do today they would probably be better off. For that reason I think they're loudness if fully justified.

<comment><USER4> I don't think that's actually true though. Sure, maybe if you _only_ hang out in SF and don't know anything about business and just believe what you hear about startups, then you might have issues.

It's better to just think about it for a while, read a _lot_ of different success stories, advice, etc and come to your own conclusions. But come on. Business isn't rocket science. You make something useful, work out a monetization strategy, and grow from there. That's easy enough for my kids to understand.

The disservice 37signals does is that they firstly _only_ believe that a certain business model is viable (eg selling stuff directly), and secondly they suggest that it's simple for the reader to emulate 37signals, when they know full well that to do that the reader would need to create ruby on rails, build up a big readership/following, etc etc.

Any extremist view is dangerous when taken literally and in isolation.

</comment></comment></comment></comment></comment></comment><comment><USER7> It's not that 37signals are the only ones doing what they do — they're just the best at promoting what they do differently from "conventional" business ideas. With Rework (and Getting Real before it), they're actually making "challenging conventional wisdom" part of their business.

</comment><comment><USER8> For better or worse, examples of companies like 37Signals are used because their approach is empowering, and their confidence about it is reassuring.

IME most hackers are in a situation where they don't know how/want to deal with investors and don't want to sit around with business types and think up monetization strategies. It's a great feeling that you can just build something with barely any overhead and start making profit early.

</comment><comment><USER9> They're not a counter-example. They're just an example.

Anyway the question is rhetorical since you know the answer is "to pick a fight", which you openly admit to doing yourself right here : [http://remarkablogger.com/2010/05/03/how-i- got-50k-visitors-...](http://remarkablogger.com/2010/05/03/how-i- got-50k-visitors-to-my-blog-in-one-month/)

The linkbait is starting to smell a little fishy :(

</comment><comment><USER10> Google serves this role a lot for the opposite model. How many times have you heard "don't worry about your business model, just get big and you'll figure it out. It worked for Google." I've heard that from so many respectable Silicon Valley investors, and it's made me cringe each time.

The real question is "why do people who give advice always do so in such black and white terms?"

<comment><USER11>
      The real question is "why do people who give advice
      always do so in such black and white terms?"

My guess is that many people want to hear their personal hopes and biases confirmed. Hate to go to meetings? Sweet; I just read that meetings are toxic! These guys are brilliant!

Never mind the lack of context or backing evidence for various aphoristic claims. The folks who read what they want into such things don't care.

When you hear what seems to be simplistic black-and-white advice, try flipping it around to the opposite, and see how hard it would be to rationalize a belief in that point of view. TDD is good - TDD is bad, OOP is epic - OOP is toxic; Stay small. Grow large.

It gets to a point where such proclamations are little more than grammatically correct sentences, and all meaning is provided by the reader.

</comment></comment><comment><USER12> So, "charging from day 1", and "entering a saturated market" are rebellious 37s-isms? Seems like those _are_ the conventional business principles.

<comment><USER13> In the internet world it is hugely rebellious.

<comment><USER4> That's just not true. At all. Look at websites for sale on sitepoint, ebay, etc. There are millions of websites, making very decent profits. You just don't hear about them much.

For every startup like twitter that doesn't really seem to care too much about monetization, there's probably 1000 websites making $1m+ a year in profit. Guess which gets all the press though?

<comment><USER13> >There are millions of websites, making very decent profits

Millions?

I highly doubt it.

Those that make a profit do it largely on the backs of ads, which isn't what is being discussed. We're talking about actually charging for a web property which remains shockingly rare.

<comment><USER4> Yeah. Because earning money from advertising isn't real money is it. It's imaginary money you can't actually use for anything. You're absolutely right. How silly of me.

<comment><USER13> That's some cutting sarcasm there. You must be a grizzled internet vet.

Only it's asinine given that what we're talking about is CHARGING, not running ads. Meaning "To use Hacker News you need to buy a $5/month subscription".

I look forward to what your rapier wit comes up with next.

</comment></comment></comment></comment></comment></comment><comment><USER6> Because they are the self-selected standard bearers for that counter-example and because they evangelize the "getting real" business model. It doesn't mean that they are the only example, there are many.

</comment><comment><USER14> (a) Because we're pretty sure they weren't bitten by radioactive spiders and we don't believe in supernatural causes for business success, and (b) because it only takes one counterexample to prove any given bit of business orthodoxy false.

Appeal-to-37signals is definitely a crutch argument. But that doesn't make it an invalid one.

</comment><comment><USER15> Among a wider tech audience (i.e. outside HN), I actually hear Craigslist as the counterexample more often, when it comes to successful tech companies that are run as normal businesses rather than startups (no interest in IPOs or exits, not much interest in rapid growth, suspicion of investors, etc.).

</comment><comment><USER16> > I'm tired of the startup elitism culture.

You have no clue how necessary it is. They are elitist.

They have taken on something most others haven't because, they are intelligent and willing to bet on their own abilities. That alone puts them in a rare percentage of elite.

</comment><comment><USER17> Pick a fight. - Getting Real.

</comment><comment><USER18> Does any one have numbers of 37signals success.

Revenue, Profit, Customer list?

</comment><comment><USER19> I annoys me that people never seem to realize that 37Signals is a company that has "won the lottery", as David likes to say when pejoratively describing the success of companies that have chosen a different route, in a major way with Ruby on Rails. The popularity of Rails is a huge contributing factor to the success of 37Signals. And without Rails, nobody would ever have picked up any of their books. 37Signals is a popular counter-example because they promote themselves, and the vast majority of their ability to promote themselves through talks and books is direct result of hitting a grand slam with Rails.

<comment><USER20> I would guess a greater percentage of their customers have never heard of Rails.</comment></comment>


Temple OS review by the Linus Tech Tip channel [video] - <AUTHOR> https://www.youtube.com/watch?v=LtlyeDAJR7A <comment><USER2> YouTube video titles are ruining internet history. And probably it is more YouTube recommendation-engine guilt, than creators themselves. I hope big YouTube creators team up and build some sort of manifesto or code of conduct to fix this. They can inspire other creators and also educate viewers to appreciate better titles and thumbnails too. They have the power if they do it as a group.

Even good content from big Youtubers needs click-bait and vague title on Youtube to be successful.

<comment><USER3> I avoid almost all videos with click bait or "YouTube face".

I reckon I miss a chunk of decent, probably-tolerable content, but the feed my cookies get seems pretty clean because of the effort.

</comment></comment><comment><USER4> Ring 0 is genuinely fun. Cooperative multitasking is super easy to write for and reason about. Having a known fixed screen resolution makes designing UIs much easier.

Sure it all sucks for the users, but if you are a programmer I encourage you to once in your life deep dive into old school coding on a machine that you control completely. You can pump out powerful code so much faster! It is a serious 2x-3x speedup.

Until another process trashes your memory because flat memory layouts don't offer any protection. That sucks. But up until then, lots of fun!

<comment><AUTHOR> I would love to understand the special file format terry created, which allowed him to insert the animated icons into what is essentially just an ASCII file.

</comment></comment><comment><USER5> The video is not bad but as I watched it when it came out I thought that they missed what for me is the most interesting part: how the console/debugger/ui combination is fully hyperlinked: [http://www.codersnotes.com/notes/a-constructive-look-at- temp...](http://www.codersnotes.com/notes/a-constructive-look-at- templeos/#shell)

There are precedents of that though: from what I've seen in videos and read in manuals, the integrated LISP environments like Genera did have that much earlier. That was built by teams of people with way more resources than him.

I think Terry Davis was right in that some valuable things have been lost in modern computing systems.

BTW, today I watched a demonstration of an IDE from the 1990s linked from another HN discussion which also hyperlinked things like the debugger (gdb) output etc.: [https://www.youtube.com/watch?v=pQQTScuApWk](https://www.youtube.com/watch?v=pQQTScuApWk)

It was the company that made Lucid Emacs (later XEmacs) which they built for this purpose: graphic elements combined with monospace text.</comment>


Making sure crypto remains insecure [pdf] - <AUTHOR> http://cr.yp.to/talks/2014.10.18/slides-djb-20141018-a4.pdf <comment><USER2> Bernstein on a "thought experiment", analyzing how government could have deliberately weakened cryptographic standards through various means. It's actually quite compelling, given that we know DES key size was weakened by the NSA back in the 70s, against IBM's will, and that we know Dual_EC_DRBG was backdoored also by the NSA a few years ago.

Bernstein's main point is that we need independent, peer-reviewed, cryptography that doesn't depend on government standardization. This talk is mostly a justification for his own work on ChaCha20/Poly1305 and DNSCurve, that were designed to be fast, constant-time and padding resistant. But the talk doesn't make mention of alternatives, except for Serpent that should have been a better cipher than Rijndael in the AES competition.

A good read. I would love to see broader adoption of ChaCha20 in OpenSSL and its standardization in TLS1.3. Google already supports it and it needs more attention from cryptographic before we start using it everywhere. It also seems that SHA-3 has failed to convince, and everyone is standardizing on SHA-2 instead, despite the computational cost. Maybe here too we need an alternative...

<comment><USER3> I would also like to see Curve25519 (as well as others) supported in _all_ browsers. It really bothers me that while at least websites are making an effort to default to ECDHE encryption with PFS, they have to resort to using the low-performance, insecure and probably NSA-backdoored P-256 curve, because most browsers aren't supporting anything else right now.

<comment><USER2> If anyone has the time and skills to implement these curves in NSS, I'm sure that the Firefox and Chrome security teams would be more than happy to enable them!

<comment><USER4> Very smart crypto implementors are already working on this codebase, aren't they?

<comment><USER2> Not being one of them myself, I can only notice that their time is limited, and many much wanted improvements sit on the backburner waiting for a smart crypto implementor to work on them.

NSS and OpenSSL are difficult codebases to work with, which may also explain why it's so hard to find people to work on them.

</comment></comment></comment></comment></comment><comment><USER5> He's right about the low entropy of many crypto random number generators. There are so many cases of this that it can't be by accident.

2013: Android random number flaw exploited for Bitcoin theft.

[http://arstechnica.com/security/2013/08/google-confirms- crit...](http://arstechnica.com/security/2013/08/google-confirms-critical- android-crypto-flaw-used-in-5700-bitcoin-heist/)

Backdoor in RSA?

[http://arstechnica.com/security/2014/01/how-the-nsa-may- have...](http://arstechnica.com/security/2014/01/how-the-nsa-may-have-put-a- backdoor-in-rsas-cryptography-a-technical-primer/)

Linus Torvalds insists on accepting Intel patch to use their hardware random number generator directly instead of just using it as one of multiple sources being XORed together.

[http://cryptome.org/2013/07/intel-bed- nsa.htm](http://cryptome.org/2013/07/intel-bed-nsa.htm)

Then there are "features" in SSL/TLS which make little sense, such as the ability to change the cryptosystem during the connection. This includes changing it to "None". That's been exploited.

[http://www.praetorian.com/blog/man-in-the-middle-tls-ssl- pro...](http://www.praetorian.com/blog/man-in-the-middle-tls-ssl-protocol- downgrade-attack)

<comment><USER4> Regarding Android: not only could it be an accident, it almost certainly is an accident. For instance: the Android RNG flaw didn't stem from a single coherent design flaw, but rather from the meta-flaw of relying on application- layer (or in this case runtime-layer) randomness, and not nailing the order of initialization in all the components. It's easy to see why this would have happened by accident: (a) the belief that runtime-layer randomness is better, more performant, more reliable on mobile platform and (b) the lack of understanding that a single central kernel-level RNG is superior to app-layer RNGs (which is a relatively modern idea).

Regarding RSA: that's not a backdoor in RSA. That's a supposed backdoor in BSAFE, a library sold by RSA. The story pertains to BSAFE's support for the Dual-EC PKRNG. (Of the supposed backdoors propagated by the NSA, by the way, this is probably the most credible).

I'm not sure what your allusion to Torvalds was meant to indicate.

The SSL/TLS downgrade attack you linked to didn't have anything to do with the "None" ciphersuite, or re-negotiation.

<comment><USER5> _I 'm not sure what your allusion to Torvalds was meant to indicate._

This. Right here is where Linus Torvalds sold out:

[https://lkml.org/lkml/2012/7/5/425](https://lkml.org/lkml/2012/7/5/425)

FreeBSD didn't:

[http://arstechnica.com/security/2013/12/we-cannot-trust- inte...](http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and- vias-chip-based-crypto-freebsd-developers-say/)

<comment><USER6> Read carefully what Linus actually wrote, not what you believe he writes. Here he suggests an even better implementation than the one actually implemented afterwards: feeding hwrng to the pool just like the all other sources. The last time I've checked (a year or a two ago) the hwrng was there but had the special treatment, not passing the same path as the other sources.

So it's more "why wasn't hwrng treated as the other sources later" than why he wrote what he wrote here.

<comment><USER4> I think Bernstein agrees with this, for what it's worth. I could be remembering wrong.

<comment><USER7> IIRC, Bernstein actually disagrees with (almost) any use of rdrand. Consider, as a toy example, an rdrand that poisons a register, so that xor'ing it with anything results in a known value; this might be worse than useless.

([http://blog.cr.yp.to/20140205-entropy.html](http://blog.cr.yp.to/20140205-entropy.html): "imagine RDRAND microcode that's looking at the randomness pool that it's about to be hashed into")

I'm not sure I agree with Bernstein here.

<comment><USER4> I feel like I remember him saying something about how as long as it's just another thing hashed into the randomness pool, it's not that big of a deal. But I haven't seen that in writing anywhere. I could just be wrong.

<comment><USER7> I cannot find anything like that for "rdrand site:cr.yp.to"; it is a reasonable position, but I don't think it's Bernstein's.

<comment><USER4> No, I mean, this is something I thought I heard him say in person.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> This is a fun slide deck, but if you'll forgive me for sucking some of the mystique out of it: it's just a reframing of DJB's hobby horses:

* The group that standardized AES rejected cache timing as a viable attack vector: [http://cr.yp.to/antiforgery/cachetiming-20050414.pdf](http://cr.yp.to/antiforgery/cachetiming-20050414.pdf) \--- more generally, that constant-time algorithms and constructions (a feature of virtually all of Bernstein's work for the last 15+ years) aren't taken seriously in industry. Also helpful to know: there's a defensible argument that Bernstein more or less started AES cache timing research.

* Side-channel attacks weren't taken seriously by TLS, and Bernstein is affiliated with one of the research groups that found a TLS side-channel attack: [http://www.isg.rhul.ac.uk/tls/Lucky13.html](http://www.isg.rhul.ac.uk/tls/Lucky13.html)

* Application-layer randomness is a bad idea, and, like Nacl does, everyone should just use a single, carefully audit kernel RNG: [http://blog.cr.yp.to/20140205-entropy.html](http://blog.cr.yp.to/20140205-entropy.html)

* Protocols and constructions should be designed to minimize dependence on randomness, the way DJB's EdDSA does: [http://ed25519.cr.yp.to/ed25519-20110926.pdf](http://ed25519.cr.yp.to/ed25519-20110926.pdf)

* Crypto performance is both not taken seriously as a research goal and an excuse for the deployment of terrible cryptography. This isn't so much a hobby horse of DJB's as it is _his entire research career_ : [http://cr.yp.to/cv/research-net-20070115.pdf](http://cr.yp.to/cv/research-net-20070115.pdf)

* DNSSEC, with its core design goals of "sign-only", "sign offline", and "sign from the root down" is a terrible idea. A sane design would look more like DNSCurve: [http://dnscurve.org/](http://dnscurve.org/) (helps also to know that DJB has a longstanding feud with both the design team for BIND, the flagship DNSSEC implementation, and with Namedroppers, the IETF DNS standardization list).

Unsurprisingly, considering the source, these are all really great important ideas. Bernstein is one of my heroes, and I'm certainly not trying to take him down a peg here. I just thought it might be interesting for people to know that this deck is less a revelation about cryptography than it is a survey of DJB's research over the last 15 years.

I'm surprised he didn't take more time on RC4, which he was closely involved with breaking. The story about how something as dazzlingly broken as RC4 could have gotten so entrenched in the industry is much more interesting than the story about how AES was standardized despite its performance relying so much on table lookups.

<comment><USER8> > Application-layer randomness is a bad idea, and, like Nacl does, everyone > should just use a single, carefully audit kernel RNG

In Linux we already have this with /dev/random, right?

<comment><USER4> Yes, modulo "carefully audited", but the problem isn't that it's not possible; the problem is that so few applications rely on it, and that there's folklore encouraging people not to use it.

[http://sockpuppet.org/blog/2014/02/25/safely-generate- random...](http://sockpuppet.org/blog/2014/02/25/safely-generate-random- numbers/)

<comment><USER9> Are you saying that that article is wrong? I was under the impression that /dev/random and /dev/urandom on Linux were exactly the same thing, but with urandom not being limited by the (very questionable) entropy counter.

I'm pretty sure they are _exactly_ the same on many of the BSDs.

<comment><USER10> The thing is, /dev/urandom is not even limited by the entropy counter when there is _no_ entropy in the system at all. That was the reason for the RSA factor collisions: The software just used /dev/urandom during boot time when the embedded systems did not have enough entropy available. As a remedy the libreSSL team asked for a Linux syscall with the feature to block if and only if the random pool has not been seeded with at least 128bit of randomness: [https://news.ycombinator.com/item?id=8049180](https://news.ycombinator.com/item?id=8049180)

<comment><USER4> That's a Linux bug with a universally-deployed userland workaround. There's no question that urandom should work on Linux the way it does on FreeBSD, but that's not a reason to avoid urandom in userland software. The death toll from avoidance of urandom is enormous; the death toll from this bug... isn't.

<comment><USER11> I would say it was both a Linux and a application bug, you could just open an fd on both random and fallback onto urandom or even better supplement random with a prng such as haveged.

<comment><USER4> "Supplementing" random(4) with a userspace PRNG is exactly the anti-pattern that Bernstein is talking about.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Re: timing attacks - can these be protected against by simply inserting into a protocol a mandatory random sleep that is strictly larger than the worst case run time of the crypto implementation? For example, if it takes up to 1s to run the crypto, would a protocol that required a usleep() of uniform_random(5s..10s)?

Such a scheme would obscure any variations in timing, right?

I ask because I have been thinking recently about the cost of "realtime", when many use-cases don't actually need it. Bittorrent exploits this idea - multicast is hard and most methods never really worked well enough to become popular. Then bittorrent comes along and gives up on the idea preserving an _ordered_ , realtime-streamable transmission. In return, bittorrent got a lot of other features and became a very useful tool.

As these slides mention - it is easy to be blinded by a supposed need to make everything fast.

(brainstorming) Perhaps something like a modern variation on the batched store-and-forward used in the old FidoNet could be useful for non-interactive needs; instead of trying to save on long-distance fees it tries use ideas like the usleep("many seconds or more") and much larger (slower) key sizes.

/* Given the tone of those slides, I would guess that DJB just saw PHK's amazing "Operation Orchestra" talk? BULLRUN? "PSYOPS for nerds"? The lesson is important either way. */

<comment><USER4> Apart from the fact that adding noise just increases the measurement cost, the "add random sleeps" solution has two other problems, one small and one big.

The big one: it implies that you actually know what the side channel is, so you can sleep at a useful point. The virtue of relying solely on constant-time operations is that they're constant time by design. You don't have to worry about how the variable-time operations are implemented, because there aren't any.

The smaller problem is that you have to make sure that your noise function is not itself a target of attack, which can be a little tricky because your noise function must be extremely, extremely cheap to compute.

There's also the obvious "non-problem" that reducing a function to it's lowest common denominator of performance defeats the purpose of high-speed cryptography and variably-timed implementations in the first place.

<comment><USER13> _Random_ sleeps, as you say, have the problem that they don't eliminate the timing side channel, but just add noise to it. However, as robryk points out below, you can _eliminate_ the timing side channel entirely, assuming you know what it is, by sleeping until a predetermined point. In pdkl95's example, you could sleep until 1.1 seconds after the cryptographic operation was initiated, then sending your response. The predetermined point could be determined randomly as long as the random number generator is constrained not to return a point that's so early that the crypto might still be running. But randomness does not help in this case.

<comment><USER4> You addressed the "apart from the fact" point in my comment, but not the meat of it. I point that out because someone else already brought up the measurement cost issue; my point was that there are other concerns.

Also, my comment directly addressed the notion of a lowest- common- denominator sleep.

I think maybe you meant to respond to a different comment?

<comment><USER13> No, my response is attached to the correct comment of yours. I directly responded to the two "problems" you brought up, but I will now attempt to do so in more detail, in case the problem is that my comment was not clearly expressed.

You say that adding sleeps only helps if you know what the side channel is. That's true; for example, adding sleeps won't help at all against power analysis, acoustic analysis, or cache timing attacks. But that's also true of other side-channel countermeasures. For example, using constant-time operations (as Bernstein suggests and you endorse) probably won't help against attacks using those other side channels either. Most side-channel countermeasures are only effective against the side channels they're intended to protect, or not even those.

But pdkl95 was specifically talking about over-the-network timing side-channel attacks on a protocol. Adding sleeps _will_ defend against that, even if you don't know which part of your code has variable timing. For example, Futoransky–Saura–Waissbain 2007 published "ND2DB", a feasible over-the-network timing side-channel attack on database indices. Sleeping so that the time in between network transactions does not depend on any of the data being transmitted will defend against ND2DB as well as any timing attack against your cryptosystems, while reimplementing your cryptosystems to use only constant-time operations will not defend against Futoransky's attack.

TheLoneWolfling pointed out correctly that you can only do this imperfectly in the presence of concurrency and caches, because the network response may take longer to send if, for example, your data has been swapped to disk in the interim. That is true, but I think that you can still reduce the information leakage by two to five orders of magnitude with this approach. For example, if you choose 1100ms as the time interval between receiving the request and sending the response, and 0.1% of the time your response is delayed until 1108ms because of paging in a single disk page, you are leaking about 0.01 bits to the attacker per transaction. If your timing varied over about a 50ms range and the attacker can measure latency to within 50μs, you would have been leaking about 10 bits to the attacker per transaction.

Second, you say that you have to make sure that your noise function itself is not a target of attack, which I take to mean that you must ensure that it doesn't leak information either; for example, the predictable cycling of the low-order bits of old "rand()" implementations could tell an attacker whether the process they connected to had handled transactions from other clients in between transactions to the attacker.

While this is true, I agree with you that it is not a big problem. Here's why. As I said, randomness does not help in this case, so you can simply pick a constant time interval, or one that only depends on data the attacker can already observe, such as the response size; or you can use any CSPRNG to generate a time to add to the constant time interval.

I didn't say anything about this before, but I also agree that it's (usually) a non-problem to make a transaction's average-case time the same as its worst- case time, but I don't agree that doing so "defeats the purpose of high-speed cryptography", because high-speed cryptography generally reduces the worst- case time to an acceptable time.

Is that better? Please correct me if I've said something incorrect above.

<comment><USER4> That's much clearer to me. I think we probably agree more than we disagree.

My point, as you've acknowledged, is simple. I think, for a bunch of reasons which are more and less easy to mitigate depending, it's a good rule of thumb to just avoid key-dependent side channels altogether. If you know what you're doing, you can shrink the risks. I'm dubious about whether they can be eliminated.

But even if one is the kind of person who can argue eloquently and accurately about those risks on a mailing list (nb: not alluding to you here), one is unlikely in my experience to be the kind of person who can actually implement countermeasures to these problems reliably. I've reviewed lots of expertly developed cryptosystems and found exploitable problems. My experience suggests that even good implementors do not tend to design systems from the vantage point of attackers, which squares with my experience of every other kind of software security as well.

A caveat to all of this is that it's easy for me to opine about what I think good conservative rules of thumb are because my technical depth doesn't extend to safely implementing variably-timed crypto operations. A subject matter expert might be able to refute a lot of what I think.

Because this is a fluffy comment, a quick shotgun blast of technical responses, none of which beg for rebuttals (but feel free):

* I can think of cases where randomized delays on one code path failed to eliminate timing leaks on other code paths that turned out to be relevant to attackers.

* I'm skeptical about exploitation of microscopic timing leaks; I don't even worry about memcmp timing, really. Other people are less skeptical, and there's a line of research pursuing statistical filtering and heuristics to bring those timing channels into reach. Also, there are some secrets that are attackable essentially indefinitely.

* My thoughts about worst-case timing are probably poisoned by client reactions to the idea of slowing down crypto operations at all.

<comment><USER13> I agree, except that I'm not skeptical about exploitation of microscopic timing leaks.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> So subtlety and obfuscation to make good ideas sound bad (serpent), and bad ideas attractive (in the interest of performance and practicality).

So when any standards body recommends a particular cryptographic approach, we should ask why, and then why again.

<comment><USER15> Currently they say performance and performance again. Sometimes they say nothing. Sometimes there is a good reason, sometimes there isn't. Sometimes they want to protect, sometimes they want to attack. That's the problem when you give one institution the job to do both.

</comment></comment><comment><USER16> A previous version of this slide set has been published and discussed here:

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

I did put up a version of those older slides in markdown format on Github here:

[https://github.com/pflanze/slides- djb-20140710/blob/master/s...](https://github.com/pflanze/slides- djb-20140710/blob/master/slides.md)

(Perhaps someone feels like forking and merging in the changes?)

</comment><comment><USER17> Very eerie. Scary to imagine that the very systems we rely on are fundamentally flawed even more so than generic "NSA back doors," but down to policy of implementation.

<comment><USER18> They keep saying China is a big enemy, so it would not be surprising if they have growing resources to start exploiting these kinds of vulnerabilities as well. Should stop backdooring stuff in the name of terrorism because the economic and political damage of enemy states with growing IT resources is far worse IMHO.

</comment></comment><comment><USER3> Dan, your sliders are hard to read online, because you make us read the same slide four times, just for an extra sentence on each. It's distracting. So please just put together the "full" slides when you put them online.

<comment><USER4> The supposition here is that maybe Bernstein didn't consider that raw presentation foils were harder to read online than slideshows?

</comment></comment><comment><USER19> In other words, all crypto is broken?

<comment><USER20> Technically, I think it is only saying that all crytpo _you know is not broken_ is broken.

</comment></comment><comment><USER21> I don't think that most of the problems stem from the NSA, most of the problems stem from the fact that security is hard, and we don't culturally have a proper appreciation of this.

We love complexity, we love adding features and wrappers and creating libraries, and when it comes to security this complicates things very quickly. You end up with massive specifications, layers of dependencies, and lots of code. And in many cases a single bug in the code can compromise the entire system.

In security, complexity is very much the enemy and we don't apply that mentality forcefully enough.

The crypto world is evolving quickly, and new vulnerabilities appear. Backdoors appear, ciphers get compromised, this or that RNG is shown to be flawed, etc. And when something that your application uses gets broken, are you going to know? If you do know, are you going to be able to swap it out for something more secure, or is that going to cause a lot of pain and dev time?

Lots of applications are going to prefer the single patch hotfix to the system redesign. And this introduces more weaknesses, because often the hotfix only addresses the single attack, and not the core vulnerability that made the attack possible. Future attacks may be harder, but they haven't been made impossible. (But... it's good enough, right? It'd be like, way harder now to create an attack... right?)

Building properly secure applications is hard, because it requires you to be minimalist, modular, and it requires you to pay attention to the latest security problems and be aware of the types of problems you can introduce when you implement something. Security is incredibly nuanced and you have to be properly aware of all the nuances. A single weakness in your entire stack can affect your whole system if you haven't carefully configured your applications.

Crypto is broken because crypto is hard, and application builders will take the easy way out, often without realizing that they're taking the easy way out. Although the NSA has been shown to be an issue, most of the problems seem to come from our own ignorance when trying to build secure applications, and there's no silver bullet.

Creating reliably secure systems is only possible when working with simple systems. Right now, the Internet is built with a ton of complexity. Operating systems are built with a ton of complexity. There are many libraries with different implementations and they all interact together in ways that are difficult to track. (IE shellshock... who would have thought that _Bash_ would be vulnerable?). We aren't going to have real security until we melt all of this complexity away, and until we train ourselves to view complexity as an enemy, and until we culturally appreciate how difficult and nuanced security is. And that's going to take a long time and a lot of effort.

</comment><comment><USER22> Does it seem ironic to anyone else that this was served over HTTP?

</comment><comment><USER23> Crypto insecurity is just one of many concerns and it is missing somewhat of the point. There will always be debate over it.

There is a chilling effect that big tech companies in the US have been working on side channels for nearly any protocol that is ever developed. There needs to be research into side channel resistant crypto as well.

But what about the bigger growing trend in computing that is causing more troubles (dependency growing system wrappers)?:

Has anyone else noticed the trend for wrappers over increasingly larger and larger parts of operating systems? For example systemd ([https://en.wikipedia.org/wiki/Systemd](https://en.wikipedia.org/wiki/Systemd)) while good for providing automation provides even more system administration power by controlling package managers.

Docker contains configuration information for the full app that is being deployed contained within that container as well. It will take quite some time to make docker more secure, and using it may contain some level of attacks.

And hypervisors as well are larger and larger in size as well. There is becoming an increasing standard for the amount of code in frameworks, platforms, operating systems and more for interoperability.

While these are good things that need to happen as fixes need to be quicker, they are also bad things in that they provide newer larger attack surfaces. Cloud computing is also becoming more and more rewarding for heavyset computation and sharing of resources. The ambiguity in choice of it all means that there will inevitably be a plethora of choices in the cloud.

The dependencies in frameworks and how we develop software has continously grown over the years as well to the point that people are using things like versioneye: [https://www.versioneye.com/](https://www.versioneye.com/) to sort changes in it all.

While diversity is good and the cloud ecosystem is becoming more profitable. Why is there almost no security company focused on making the "cloud" tamper resistant? (i.e. monitoring docker containers and looking for misconfigurations etc even on github) There definitely should be a working effort in that retrospect.

It is also equally problematic that cloud software will be ambiguous in design. Cloud software that is built to be fast may use a custom in-house Just-In-Time code engine for faster database or code execution which may be harder to really address security wise.

In retrospect there are many security companies that are working towards securing the appstores, why should they not be working towards securing/integrating with cloud providers?

There should also be more opensource security anti-viruses besides just clamav. For people to be secure there should be a newer trend into opensourcing specific security modules and working towards a functioning operational level of configuration/management security as well as malware detection.

</comment><comment><USER24> > Try to scare implementors away from constant-time software. e.g. "It will be > too slow." "It's too hard to write."

More generally, try to scare implementors away entirely. "Never roll your own crypto." Leave it to the experts -- i.e., NSA.

<comment><USER25> Erm, no.

There are good reasons not to roll your own and none are to do with the NSA. One is that your own is likely full of flaws that you can't see but an attacker will spot in seconds.

It's easy to write crypto you can't break yourself.

<comment><USER4> Not so much "easy" as "inevitable". _Everyone_ can write crypto they can't break themselves.</comment></comment></comment>


Master Foo Discourses on the Graphical User Interface - <AUTHOR> http://catb.org/esr/writings/unix-koans/gui-programmer.html

<comment><USER2> I liked 'Master Foo and the Script Kiddie' more... <http://catb.org/esr/writings/unix-koans/script-kiddie.html>

<comment><USER3> Hah, that was great!</comment></comment>


Climate denialism outside the US (and newly within the US) - <AUTHOR> https://theintercept.com/2018/04/17/climate-change-denial-trump-germany/ <comment><AUTHOR> I changed the title to better reflect the content of the article. The article is about the more subtle kind of climate denialism from politicians and industry outside the US, which is also similar to the kind of climate denialism that is present currently in the US Democratic Party and its industry sponsors. It is particularly relevant to this community because it is the kind of thinking that is widespread here.</comment>


Online web browsing logs (including porn) of 1mln+ people across Africa leaked - <AUTHOR> https://www.iafrikan.com/2019/12/31/vpnmentor-pornography-web-browsing-south-africa-internet-history-conor-isp/ <comment><USER2> From the article it looks like it's just south Africa.</comment>


Lvm:a tiny virtual machine based on instruction set - <AUTHOR> https://github.com/Leviathan1995/lvm

<comment><AUTHOR> welcome to pull requests or star.</comment>


Don't believe the American Heart Assn – saturated fats aren't likely to kill you - <AUTHOR> http://www.latimes.com/opinion/op-ed/la-oe-teicholz-saturated-fat-wont-kill-you-20170723-story.html <comment><USER2> As someone with high cholesterol and pectoris angina at 39, I urge people to listen to their Cardiologist over the socalled Internet Experts and even GP's who are falling for pseodo science.

The fat story certainly is complicated, and we do know sugar and instant carbs can be worse, but that doesn't mean most saturated fats are good especially is excess, and the whole story changes if you happen to have familial hypercholesterolemia.</comment>


Ruby 2.0.0-preview2 released - <AUTHOR> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/50443

<comment><USER2> Just a reminder that the spec for refinements continues to change radically: <http://bugs.ruby-lang.org/issues/4085>

As far as I understand it the current spec is to have "using" be available only to main and only apply in the file scope. IMHO this makes the feature nearly useless.

<comment><USER3> If you explore the topic, there are solid reasons from performance, to vm ports, to readability for why refinements have been curtailed. I'm quite happy with this. The original refinement support would have held ruby back, even if it had its uses.

<comment><USER4> ^^ What an apologist...

</comment></comment></comment><comment><USER5> This is fantastic.

The thing I like the most about ruby is how much thought is put into code readability and programming experience.

My favorite features of this release:

1\. Keyword arguments: I can stress how important this is for code readability and also prevents some bugs.

2\. Refinements: This is going to make code easier to maintain and more "custom". I can't wait to add a few things we constantly use on String etc.

<comment><USER6> It's amazing that considering Ruby's philosphy we didn't have named arguments until now. I think this was a case where the idiom of using hashes as named arguments working well enough that the core team didn't feel the need to address it earlier, still proper keyword arguments are going to be great.

I thought Matz was going to drop refinements for 2.0 for now?

<comment><USER7> As a Python dev keyword arguments are among my top language features. Kinda surprised that Ruby doesn't have them yet.

On a slightly off-topic note, what's the best way to dive into Ruby coming from (strong) Python background? I bet the syntax wouldn't take more than a weekend to get used to but I'm more interested in the less trivial stuff (semantics, idiomatic style, dev environment, 3rd party lib ecosystem etc.)

<comment><USER8> For the dev environment you can use rbenv or rvm and your favorite text editor. <https://www.ruby-toolbox.com/> is a good source for 3rd party libs. About idiomatic style I have learned from reading code from some popular gems.

</comment></comment></comment></comment><comment><USER9> Dtrace is such an awesome technology and the support in Ruby 2.0 is going to help improve a lot of projects.

<comment><USER10> "DTrace can be used to get a global overview of a running system, such as the amount of memory, CPU time, filesystem and network resources used by the active processes. It can also provide much more fine-grained information, such as a log of the arguments with which a specific function is being called, or a list of the processes accessing a specific file."

For anyone else that wasn't aware what Dtrace does.

Wikipedia Link: <http://en.wikipedia.org/wiki/DTrace>

<comment><USER9> And the overhead is extremely minimal which allows you to collect data in production while an application is running (without restarting).

</comment></comment></comment><comment><USER11> OT: does anyone else notice that the Japanese text doesn't render correctly (in Chrome and Firefox on Linux & Windows) unless they manually change the encoding to EUC-JP? Why doesn't it work with Unicode, for the Ruby ML, of all things?

<comment><USER12> The server does not send the charset in the response headers, and the document that is generated does not contain a charset like this:

        <meta charset="utf-8">

Either of those two options should fix the page, but I assume Japanese browsers have different default charset than ours since no one has fixed it yet.

</comment></comment><comment><USER13> Anyone else getting compile errors with the latest clang on mountain lion?

num2int.c:82:21: error: expected ')'

        sprintf(buf, "%"PRI_LL_PREFIX"d", NUM2LL(num));

                        ^

<comment><USER14> Is that even valid C code?

<comment><USER15> Yes, if PRI_LL_PREFIX expands to a string literal, the literals get merged together.

<comment><USER16> Ruby supports this too but it will be removed in the future (3.0). The preview doesn't show a warning but 2.0 will.

Source: <https://bugs.ruby-lang.org/issues/6265>

Btw, PRI_LL_PREFIX is defined in Ruby's _config.h_.

</comment></comment></comment></comment><comment><USER17> Does anyone know what ever happened with Kiji, it seems a generational GC for Ruby has already been coded twice, yet in 2.0 it seems the only big change is the CoW friendly GC

<comment><USER18> I don't know the specific characteristics of Kiji, but I know that it is not a real generational GC. A generational GC that doesn't break every C extension is impossible because Ruby passes around direct pointers, so Ruby objects can't be moved in memory.

That being said, I'm not a language or VM guy, so take what I say with a grain of salt.

</comment></comment><comment><USER19> Calling it: There will be a blog post titled "Ruby Two's Day" on release.</comment>


GWT: Last updated, 2012 - <AUTHOR> https://developers.google.com/web-toolkit/

<comment><USER2> Just yesterday I was wandering if GWT is still being maintained since I was evaluating it for a customer project. It seems to be stagnating, perhaps the devs need to focus on other things or have moved on. I don't get the impression that GWT is in any way strategic to Google so they might cut it.</comment>


Evolution of Linux kernel size - <AUTHOR> http://lkml.org/lkml/2011/11/10/267

<comment><USER2> Interesting. I'm not sure if this is a good sign since it can be a bloat indicator. Certainly most of it should be due to drivers being added. What I'd like to see is the size of the core kernel bits for say x86 or x86-64 only (i.e. with drivers removed).

</comment><comment><USER3> Boo, either crashed or offline? I can't seem to access it.</comment>


Rumor: Bruce Willis Wants To Sue Apple Over iTunes Music Ownership - <AUTHOR> http://techcrunch.com/2012/09/03/bruce-willis-itunes-music-library/ <comment><USER2> Rumors.

From TC.

Great.

 _Like many of our peers, we also fell for this good old British tabloid rumor at first. We have updated the story now that Willis' wife has denied that this story was true._</comment>


Ask HN:  Ideas for Monetizing? - <AUTHOR>

Hi all-
I currently am working on a site that is similar to one techcrunch posted a few days back.  I have a super duper early demo if you want to take look available here:
onedatedaily.heroku.com
The concept is this:  Each day (eventually each hour) a new dater of each sex will be featured on the front page.  People will then be able to get some basic information, and if they like the featured dater, they can send them an email through our site.  This will likely be form based and require certain elements to reduce spam and stalkers (also we don't reveal the dater's email to avoid stalkers and weirdos).  If the dater likes what the person has to say, they can email them back.
The question is how to monetize.  I have a couple ideas and was wondering what you all thought:
1) Force anyone who wishes to email the dater to pay 1$ per email (some of this could be used to "pay" the dater for listing themselves.  A kind of incentive to get more daters)
2) Graduated scale emailing.  The first 50 free, then 1 dollar for the next 50, then 3$ for the next 50 etc.
3)  Force the featured dater to pay per email from vetted emailers. .10 an email or whatever
4) Freemium model -- Get more information and more tools by signing up with us.  Email of the day etc.
Thanks for looking guys, all suggestions welcome for both monetization and user experience stuff.  The UI is pretty suck, but I'm working on it.  I think the idea is decent, I'm just sorry I got beat to the punch by that one tech crunch had which looked, tbh, also sucky. <comment><USER2> Seems to me that your somewhat limiting your revenue... The problem I see is no one wants to make the first move, so everyone would want to be the "featured" date and let everyone else do the "dating work" for them.

In this structure I'd think you want to charge the dater not the prospective dates.

My suggestion would be lower the barrier for prospective dates to contact your featured "date" by making it free.

1\. Charge your featured dates for the "feature" service.

2\. Charge more for "localized or placed features"... AKA I want to be featured in LA, and site-wide.

3\. Make the entire database searchable, your featured dater functionality is your hook, but no need to limit what who your members could find. (Maybe this is an extra pay feature)

4\. One thing I have always wondered about dating sites is why none of them have used alternate payment mechanics? For example, buy a date flowers from (FTD, with your affiliate code) and get 20 free contacts, sign up for netflix get 10 contacts, etc, etc...</comment>


Show HN: Metis – ECMAScript6 in-memory fulltext search engine - <AUTHOR> https://github.com/MKCG/metis <comment><AUTHOR> Hi,

I'm glad to share "Metis" which is a fulltext search engine written in ECMAScript 6 with facet capabilities. Results are not yet sorted using a TF/IDF algorithm, however sort callbacks can be provided.

This is still a WIP project and the engine API will change in the next weeks. The current revision includes a simple fulltext search with results count and facets.

It follows semantic versioning and the 1.0.0 should be released in two months.

If you want to use it, be sure to specify the current tag (0.3), as the overall project structure will changed as explained before. For example, by the revision 1.0.0, a "Query" object will probably be introduced and will be notified when the response is returned by a JS worker running on another thread.

A working example is accessible and generates 1000 documents before indexing them.

Any critics are welcomed.</comment>


First Ring System Around Asteroid (2014) - <AUTHOR> https://www.eso.org/public/news/eso1410/ <comment><USER2> At a diameter of 250KM, and with enough gravity to retain rings, does that mean it also possesses enough gravity for hydrostatic equilibrium?

If so, this qualifies it officially as a dwarf planet.

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

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

<comment><USER3> [https://en.wikipedia.org/wiki/Hydrostatic_equilibrium#Planet...](https://en.wikipedia.org/wiki/Hydrostatic_equilibrium#Planetary_geology) claims the limit of hydrostatic equilibrium for rocky bodies is ~400-500km, so probably not.

</comment></comment><comment><USER4> Could we, somehow, come up with something to add rings to earth? Not because they would be remotely useful, just to make the sky more fun to look at

<comment><USER5> Ring systems are most enjoyable to look at when you're not in the plane of the rings. From in the plane, you're looking at them side-on, and they're flat, so that's a thin line across the sky. On earth, you would always be (roughly) in the plane.

Really, you want to add rings to the moon.

<comment><USER5> Okay, an earth ring might be pretty good from temperate latitudes:

[https://science.howstuffworks.com/science-vs-myth/what- if/wh...](https://science.howstuffworks.com/science-vs-myth/what-if/what-if- earth-had-rings.htm)

I'd still rather have a terrifyingly large disco ball though:

[https://www.youtube.com/watch?v=w8I25H3bnNw](https://www.youtube.com/watch?v=w8I25H3bnNw)</comment></comment></comment>


From Rejection to Acquisition in One Year: One Startup's Story - <AUTHOR> http://blogs.sun.com/sun4startups/entry/from_rejection_to_acquisition_in <comment><USER2> It seems like the proper advice here is, "Network with your friends."

<comment><USER3> Agreed, one of the things I learned is that leads can come from anywhere.

<comment><USER4> Plus, if you're building something that is actually solving a problem for people that you know you might find that you get it right in fewer iterations than if you're only getting feedback from outside users. Being more familiar with the problem domain and the people most affected by it can certainly go a long way towards building something people can get excited about.

</comment></comment></comment><comment><USER5> "Mudge submitted an early version of AtD to Y Combinator Demo Day, Spring '09 and was promptly rejected."

I imagine that YC rejects EVERYBODY that applies to YC DEMO DAY.

<comment><USER6> I'm not sure whether this is supposed to be a jokingly phrased insight or criticism or just a plain joke, but I don't get it. Would someone care to explain?

<comment><USER7> Demo Day is where all the startups in a round demo what they've been working on. Thus, applying then would be a bit late for that round and a bit early for the next.

</comment></comment></comment><comment><USER8> Nice story, but it sounds more like a pet project which landed him a job rather than a company which was acquired.

He states _"With Automattic, I am still an entrepreneur"_ , but he's really not: He's an employee and his objective (to have a job again before he was 29) indicates that's his lifestyle preference.

Entrepreneurship isn't about finding a 'job' at another company, it's about making that company.

<comment><USER3> I thought it was making something from nothing and having an impact. Something to do with vision and all that other nonsense?

<comment><USER8> Nope. You can make tons of cool stuff and have an impact with loads of 'vision' as an employee, but you're not an entrepreneur if you're taking a paycheque and instructions from someone else.

<comment><USER3> Well, reading through your previous comments, you seem like a very knowledgeable guy who shares a lot here. I appreciate that. The insights and discussion from those who have made it and accomplished something great are why I come here.

</comment></comment></comment></comment><comment><USER9> This is a great story and I'm happy for Mudge, but I wish the story had been a bit more detailed. It pretty much boiled down to "he had this idea, some friends liked it so he didn't quit, he got acquired". When I saw the title, I was hoping for details on what made it all come together.</comment>