skysight-inc/HackerNews huggingface dataset:
This was my conclusion as well. Also, planning for negative outcomes ensures survival much better than planning for positive ones.
Maybe the previous weeks have an effect on the next, for example a low price point brings more new users that will bias the result of the next week and so forth. It's hard to make a controlled experiment... but at least it is possible to do multiple experiments over time shuffling the order in which the prices are tried.
Sensitive information doesn't exist in a vacuum. What we need to protect is more than some keys that can be carefully loaded onto a crypto processor hiding in a secure bunker. Yes, users should have security too. The point of entry matters too.

So how do you get that isolated box onto everyone's computer and phone? How do you move these users' sensitive information onto that isolated box without leaving a trace on their non-isolated computer? How do you move their keys around?

When you use two systems to process sensitive information, you have at least two problems to solve...
Want to express my thanks for all you have done for the Scala and JVM communities so far. Looking forward to seeing what's next.
I'd diagree, Game physics and scientific algorithms are often precisely where you want reproducible results.

Game physics because of lockstep networking and replays, scientific algorithms because... well, you want your results to be reproducible. Scientific method and all that.

Often times you don't mind if it isn't accurate, but that isn't the same thing as precision. You want it to be precise, i.e. reproducible.

Yes, there are cases
Nitpicking:

>> A teaspoon of sewage in a barrel of wine makes a barrel of sewage.

To be realistic, it makes a barrel of (maybe a bit cheaper) wine; alcohol kills bacteria.

(As someone that eats lunch at restaurants most of my life, I avoid reading about kitchen hygiene. Laws and sausages, etc.)

Edit: I didn't realize it, but I guess I am a typical example of cynical negativity. That alcoholic drinks are safe to drink is a feature, not a bug. And while not much of an oenophile, I do enjoy a glass of dry Spanish red. Just don't tell me about the sewage spoon.
Rust has an FFI to C, which is how it calls out to LLVM. Can you point me to the part of the codebase that codegens the basic constructs?
Show HN: Use BIOS ram hacks to make an SSH server for MS-DOS, INT 10 13h OS's
You write them to a global state volatile
Every time I read one of these posts about a clever "attack vector", how something can be gleaned from this special register, or a timing attack, somesuch, I remember about a theory that the sound of a dinosaurs scream can be extracted from the waves impact made on a rocks crystal structure.

I googled pretty hard for real life example uses of a timing attack, and now using of stale data on the register, but couldn't find anything. Does anyone know of examples of this actually being done?
This is a good idea, but I wonder about the shelf life. As more sites start to use email responses and follow ups it increases the chances that people start flagging this as spam or ignoring it altogether. Email is a valuable but delicate channel.
They've actually split the deadlines for SSL Certificates and Code Signing client certificates.

The deadline for websites to upgrade their SSL Certificates is January 2017.

In January 2016, Microsoft will stop trusting code signed with a SHA1 certificate, unless it was timestamped prior to that date. In that case it will continue to be trusted until SHA1 is found be vulnerable to pre-image attack.
> Is the compiler still allowed to optimize away the zeroing in this case?

Yes, completely. In the snippet below, the compiler is allowed to eliminate all code after “leave secrets in array c”.

{
char c[2];
... /* leave secrets in array c */
memset(c, 0, 2);
c[0] = 0;
c[1] = 0;
memset(c, 0, 2);
if (c[0] || c[1]) exit 1;
}

The compiler is also allowed to compile the last three instructions below as if they were “return 0;”

{
char c[2];
... /* leave secrets in array c */
c[0] = 0;
c[1] = 0;
return c[0] + c[1];
}
It's really absurd when people call Python 3 a "disaster". There was nothing disastrous about it. In fact, hindsight shows us that it was actually a very good path to take.

Python 3 didn't negatively affect Python 2 or earlier users. Their code still runs fine, and is well supported by a huge number of libraries. They weren't forced into upgrading against their will at any point.

Python 3 allowed the Python developers to make some breaking changes to the language and libraries. These have, without a doubt, improved the language.

Much Python 2 code, especially well-written code, can be automatically converted to Python 3 code with little to no effort. Anyone with any sensibility who has been writing new Python 2 code within the past few years has been keeping an upgrade to Python 3 in mind. Their transition should be quite painless.

Over time, more and more existing Python libraries have supported Python 3, or been replaced with significantly better replacements, as the need arose.

The fact that we see so many libraries simultaneously supporting both Python 2 and Python 3 goes to show that the community is not "divided" or anything like that.

The only downside is that it took a few years longer than people may have initially been expecting for certain libraries or frameworks to support Python 3. But at this point in time, Python 3 is a clean, usable language with very good third-party library support. Existing users weren't forced into using the new version, yet those developing the new version weren't constrained by compatibility concerns. The end result is an improved and usable language, achieved with minimal disruption.

Perl 6 is an example of a real disaster, on the other hand. It still doesn't have a truly good implementation, even after 10+ years. Not only is Perl 6 pretty much unusable in practice today, but the uncertainty it caused stunted the growth and development of Perl 5 for quite a while. It is only recently that we've seen people finally realize that Perl 6 is a lost cause, and get back to using and evolving Perl 5. Compared to Perl 6, the Python 3 development process was perfection.
Your setup sounds pretty much like mine, so it would be portable in my case. :)

Having said that, if this were available as an RBL that would also be really great.
One of the major problems with Emacs is that it's hard to isolate, debug, and rollback Elisp fragments; the only way to fix many problems is to restart Emacs. I still haven't figured out how to solve this problem with Rhine: keep (limited) history for all variables? How do we keep track of the effect of specific function callchains?
As a seasoned and experienced reverse-engineer myself, I'm (genuinely) curious where you got that impression. Do you find it unapproachable?

Assembly is the simplest language you can write a computer program in, for a certain very textbook definition of "simple" - it's just that you actually have to do everything by hand that you normally wouldn't. And yes, that can be a pain in the ass, and yes, you do have to watch out for not seeing the wood for the trees - but one thing it most definitely is, is auditable.

Bearing in mind, say, the utter briar-patch that is OpenSSL: a crufty intractably complex library written in a high-level language with myriad compiler bug workarounds, compatibility kludges and where - despite it being open source, and "many eyes making bugs shallow" - few eyes ever actually looked, or saw, or wanted to see, and when attention was finally paid to it, it was found wanting... might not assembly be perhaps better for a compact, high-assurance crypto library? Radical, I know, but perhaps an approach that's worthy of consideration.

I understand you may well be more familiar with high-level languages, and I don't know if you're confident about your ability to audit that - but I must point out, if you're auditing it from source, you're trusting the compiler to faithfully translate it. So to actually audit the code, you need to include the compiler in that audit. Compilers have (lots of) bugs and oversights too (lots of OpenSSL cruft is compiler bug workarounds, it seems?): as the article points out, existing compilers just weren't really designed to accommodate writing secure code.

Meanwhile an assembler makes a direct translation from source assembly to object machine code - that is deterministic (a perniciously-hard process with compilers) and much more easily, and automatically, auditable and indeed directly reversible.

To be clear, I'm not suggesting we replace, say, libsodium with something written in assembly language tomorrow! There are good high-level language implementations. And
inline assembly is already used in some places for certain functions, including this exact one (zeroing memory), to try to minimise the compiler second-guessing us. But as the article points out, that approach only takes us so far, and it's something we need to be guarded against when trying to write secure code.
Tell PG? You could have sent him an email.
> Yeah, but that only appeals to the people who are already committed to the JVM (or .NET), and that is a shrinking population.

Looking at the enterprise world, I would say it is still growing.
"Constantly making waves" is probably more accurate from the days back when Tony Morris was active on the mailing lists. Paul, I believe, also made a fair bit of waves back in the day, but for some reason his were always much more palatable. (He has a very good writing style and is never, that I really remember, flat out mean.)

I guess the big waves I remember are essentially about a post a week from Tony. The hoopla around Colebourne's opinions on the language[1]. And then the mystery/whatever around Pollak's involvement in the community.[2]

The later point is odd just for how much traction lift seemed to be generating, and then the overall community appeared to reject it heavily. Do note that I would still recommend it. Their community is quite nice and helpful.

And I should definitely make clear that it is very possible I just don't see the waves in other communities. I don't really see Scala's anymore; this week being a notable exception. To me, though, high tension is not exactly a good environment. Heck, for all of the flack he gets, Torvalds is usually more cordial than many of the threads I remember from this community.

[1] http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-othe...

[2] http://blog.goodstuff.im/yes-virginia-scala-is-hard
>"isn't it better to have more users benefitting from your work, and a cheaper to buy application"

Because the edge is so small it looks like the amount of user are the same and that edge is just because the price difference.
With the release of Java 8 I wonder if Scala is getting squeezed from both sides. Java 8 on one and Clojure on the other.
There is some truth in what you're saying but you're overly dismissive of the very real and not-actually-rare issues of depression, which have physical causes and treatments just like any other human ailment.

Telling someone who actually has depression--that is, a brain chemistry imbalance that causes negative feelings--to toughen up is about as helpful as telling someone with a broken leg to walk it off.
My point is that, Americans expect paying with credit card to be the same as paying with cash. In a lot of other nations, that expectation does not exist.

And you're right- a better way to do it is to have the lowest fee added to the cost.
Are there any practical applications for super-fast internet that other countries (who already have it widely available) have created? I can't think of any off the top of my head.
This seems like a poor defense choice. In Australia, a number civil rights in Australia automatically disappear if you were in the midst of committing a crime while trying to claim them.

This was ultimately to prevent stuff like burglars falling through skylights, then suing the owner of the house they were burgling in civil court while facing criminal prosecution.

I'd be staggered if it was possible to make a relatively weak "authorization" claim stick, seeing as how the police do have the right to investigate things left "in plain view" which you could argue a web server page which you accidentally sent compromising fuzz data too could fall under.

A court would also have little trouble allowing such a thing, since it's a narrow interpretation that doesn't legalize it for the ordinary citizen (though IMO I think it probably should be).
The hotfix KB 968730 for Server 2003 includes updates from hotfix KB 938397. An important thing to note from KB 938397 is that "KB 938397 will bring Windows Server 2003 to the same level of functionality as Windows XP with Service Pack 3." [1]

What that translates to is that it only gives Server 2003 SHA2 support as a client, not as a server. I.e. You can connect to sites that are using SHA2 certs, but you cannot bind a SHA2 cert to your own website in IIS 6/Server 2003.

So once SHA1 is completely deprecated, those hosting sites or legacy apps on Windows Server 2003 will not be able to upgrade to SHA2 certs.

[1] http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-w...
But it also doesn't offer many of the benefits and much of the functionality that Scala offers. A familiar C-like syntax, static typing, and so on are very important for a lot of Scala's users.
Thank you for your thoughtful and considered response to my slightly hasty one (I was half-way out of the door as I was typing it!).

You're absolutely right that contacts and location are important; I live out in the countryside and mostly work from my home office, but I think I can only do that right now because I spent most of the previous ten years in London building up the right sorts of connections to allow me to do that - and I still go to London regularly (usually weekly) and am willing to concede I may end up back there again.

With the right approach and attitude, building up connections isn't hard, but it takes a certain pushiness, persistence, and resilience (and an occasional willingness to work at less than a reasonable rate in order to secure future work - the so-called "loss leader" projects) - and in certain locations it may be much harder than others.

I guess I'm guilty of taking it for granted that everyone lives in London, SF, or NYC, where contract roles on eye-watering day-rates - the sort whereby you can work for some fraction of the year and do what you like for the rest, and still maintain an excellent lifestyle - are pretty easy to come by once you have a bit of experience under your belt.
Here in Argentina, it's very popular the "chocolate en ramas" (chocolate in branches?). It's more expensive that the usual chocolate tablets, but it's nice for presents and special events.

Photo: http://commons.wikimedia.org/wiki/File:Chocolate_en_Rama.jpg

Video 1: https://www.youtube.com/watch?v=mjxNLXbSEFA The image quality is not very good, but this shop is nearby my home. You can see how they make it from the street.

Video 2: https://www.youtube.com/watch?v=aBPqvxUdToY Better image quality.
http://www.fedex.com/us/small-business/updates/February2011/...
These types of attacks though only require one person to create a system that can reliably exploit them, and then the vulnerability will be in the wild and a more significant problem. Pulling off this type of attack is difficult, but you only need one piece of malware that has a reliable way to exploit this in a general case and then it becomes available to every script kiddie who finds some motivation for stealing private keys.

These type of attacks also might become more of a problem as more sensitive computation is done on shared machines (IE cloud compute).

So, while there's no reason to panic because these security features aren't implemented hardly anywhere, you can't let the issues sit unaddressed for long periods of time.
>> Here, have a strong cup of toughen-the-fuck-up.

You might have a point generally, but I think you miss some historical context.

A few hundred years ago, depending on location, if you made a "random snide comment" someone(s) might die. This used to be more serious stuff.

These days we have rule of law, but taking care of your reputation and social respect is certainly one of the things you find not only in the Western world but in all cultures, including among baboons. It is partly genetic.

(Consider all the muscles in your face to communicate and your language facilities; we have had lots of evolutionary pressure to be social with people. That is, if you failed in life or not was to a large degree decided by how you functioned with other people.)

The point is, it is normal, now and historically, to feel destroyed and be motivated by social respect and insults.
Note that Gandi do not offer SHA-2 certificates at all at the moment.

https://twitter.com/gandibar/status/508001036653826049
I think it would be better to ask the user to compare a place against a few others he has visited and use that to automatically compute a rating. But thats not as usable.

Another option would be to ask him to fill in a few questions.Then compute the rating using that.
Remember: it's the price-to-earnings ratio and not price-to-revenue ratio.

Amazon's stock trades at a P/E of 910 exactly because it's deferring profit to continue growing its revenue. At some point it's going to stop investing its revenue into growth and start realizing a profit on that revenue. At that point the P/E will come down.
The site was misconfigured WRT serving the captcha image resulting in the image link pointing directly to the SR server rather than being routed through TOR.
>> "for about the same income, isn't it better to have more users benefitting from your work, and a cheaper to buy application?"

Don't forget support costs. You can make the same income at each price point but at the lower one you will have to respond to lots more emails driving down your total income. Your point that more people using it could lead to higher long-term growth though is valid especially is the app is spreading via word-of-mouth. So it's an important trade off to consider.
I up voted just for the imagery. :-)
Nvidia claim a lot of things about their Tegras.
This should be the paper mentioned in the article

http://app.mnt.metu.edu.tr/system/files/images/ncomms5449.pd...
but on the other hand, it is better than having unknown security properties like e.g. ruby or javascript on node.js. While node is built on the venerable V8 engine which has strong security roots, its core libraries and dependencies are less well explored. Plus javascript is generally a terrible language for secure programming.

I'd rather have ample documentation on how to harden my PHP application than no documentation on how to harden my Node application. Security through obscurity is no security at all. Plus, many of the mitigation strategies are simply rules like "don't use mysql_query" or "use htmlentities with ENT_QUOTES and UTF-8 to escape your output", both of which can be built into a framework. See: laravel.

[edit] downvoting is much easier than formulating a response, isn't it?
So Rhine, being a Lisp, may not be a good language for implementing a big pure function involving a lot of tree transformations. Is that what I'm reading?
Clean Design
You have a page "Company". If you are a registered company, indicate its name and place of registration. That would add credibility.
Having seen a few existing designs of those, up-close and personal - actually they do have to worry about zeroisation, quite an awful lot.

And sometimes they don't worry enough either. They ought to fail a FIPS-style audit for that. But, well... they ought not to contain proprietary LFSR "crypto" algorithms, either. They are not as well audited, or as publicly designed, as they ought to be: many are as black-box closed-source as they could possibly be.

They tend to be based on extraordinarily old architectures with new bits glued on - think Intel 8051, that kind of era. If you're really lucky you might get an ARM, or at least a Thumb. People making them are notoriously hyper-conservative (most don't support ECC yet, and many don't even go above RSA-2048 or SHA-1 without going to firmware), and minimise any changes, perhaps for cost reasons, the effects of which are not always positive (actually, CFRG are discussing that general area right now in the context of side-channnel defences for elliptic-curve crypto).

So, how would you think that environment translates to writing secure firmware, or designing secure, state-of-the-art hardware? ;-)
Immune to what? Should keep the original title.
Some of this can be addressed by never giving sensitive data to remote servers. This wouldn't work for credit cards, but with Bitcoin you never need to let a non-bitcoin library touch your private key, because that's not going over https.

Similarly, if you encrypt all of your information from within a safe library before handing it out to unsafe libraries, they can't leak anything. This can add overhead and redundant encryption (and you still need to trust that the remote server processing your data is safe), but there are steps you can take to be more safe.
Someone mentioned the JVM interop of Clojure is it's main selling point. While its definitly awesome to have that great integration (I'm a heavy interop user), for me, the main strength is having persistent data structures at its base for everything. I myself played with the thoughts of creating a native runtime based on Clojure's syntax and data structures. I cant see that this project uses persistent data structures. Am I wrong? please enlighten me.
I can't believe I'd forgotten about JTAG! Yes, that's definitely more viable than decapping! <g> Same completely-doomed threat model though ("attacker has physical access, can do anything they want and take as long as they need").

Sorry, I've been dealing with a few things more recently which, uh, haven't been quite so accommodating to analysis.
Alright. If you are a web developer or you are a whatever who knows nothing about security, please read resources that apply to whatever you do.

Learning security on a topic will make you so much better at what you do and it will make you learn internal details AND best practices.

The things you build will be BETTER not just more secure

I'm really tired of reporting account hijacks and Remote code executions to startups who look at me blankly when I explain what I did
Why would you need a third party to handle that? Just analyze your logs and spam the inactive users for free.
I _believe_ that https://github.com/rust-lang/rust/blob/master/src/librustc_l... is the LLVM wrapper, and that https://github.com/rust-lang/rust/tree/master/src/librustc/m... is what does the actual generation, but frankly, I am quite bad with the compiler internals.
Eric Schmidt on building culture
This sounds like a job that only has to be done once [at this scale]. 115 machine days is a lot of computing. It's not much human time. What really counts as optimization?

I suspect it's mostly the quality of the access points and less the efficiency of the algorithm making thumbnails.

I suspect that the secondary optimization is how quickly those access points become available. In the 17 hours between the time your question was posted and this comment, more than 12,000 images could have been thumbnailed and possibly 12,000 additional resources made available or meta-data records improved.

The great thing about starting with something slow that works is that there is plenty of time to improve it [and plenty of time to decide if it really needs improving].

If the process had started at 8am yesterday, more than 50,000 images would have been converted by 8am Monday morning.

Now in the real world of bureaucracy, there can be more friction entailed in obtaining a box, sticking it in the corner, and letting it run for four months, than spending substantial human time researching and implementing a solution that looks clever and elegant. But really, the hardware for this job, even if purchased new is only a few hundred dollars.