HN user

MichaelGagnon

89 karma

Hacker working at Dasient, a Google Ventures startup building anti-malware tech for the Web. Before that I was a grad student at Harvard (comp sci). And before that I was a research staff member at MIT.

Posts3
Comments26
View on HN

Agreed.

Also, be aware that many non-expert attempts to develop compression algorithms turn out to be flawed. However, it sounds like you've developed a compression pre-processor specifically targeting JSON-like structures, which seems like a much more plausible accomplishment than a non-expert developing a brand new general-purpose compression algorithm that can beat LZW.

All that said, if I were considering hiring you I would be much more interested in your ability to rigorously analyze the strengths and limitations of your algorithm (rather than the algorithm itself). Plus, without that rigorous analysis it makes it much more difficult for me to judge the quality of your algorithm.

As far as pop-culture goes, I think Clarissa still holds the cake for female programmer characters. Acid burn (from Hackers) is a close second...

From the article: "Should the mantle of 'creator' lie with the program or the programmer?"

Strangely enough, this was the exact dilemma that Clarissa faced in in Episode 29 of Clarissa Explains it All, "Poetic Justice," in which she developed a program that generated poetry. When her program's poetry won the school's contest, she decided to publicly relinquish her award to her computer. http://en.wikipedia.org/wiki/List_of_Clarissa_Explains_It_Al...

I disagree.

Node.js and client-side JavaScript should treat security issues differently because they face different risks. E.g. A DoS against client-side Javascript is not a big deal (because it might slow down a single browser, or even just a single tab within a browser). However, on the server side, a DoS could take down an entire service which is much more significant.

Thus you could say that V8 is "secure" on the client side but "insecure" on the server side because of the different risk assessments. It is poor security practice to take software designed for one security environment and assume it will be secure in other environments. If Node.js wants to have a secure system they will need to take these security issues into consideration and harden their system appropriately.

Add together these three statements the author made:

(1) The vulnerability report exists in the "shadowy ground between the reports that are clearly crackpot and the reports which are clear enough that you can evaluate them with confidence" (from the blog)

(2) "Oh, we recognized it immediately. But it was so obviously wrong that we began to fear that we were missing something." (from the comments)

(3) "this entire investigation took five days to complete, plus another day or two to complete the necessary paperwork." (from the blog)

This blog post paints a picture that Raymond's organization does a bad job triaging reports and prioritizing investigations. It's a waste of five days to analyze an "obviously wrong" vuln report, just on the off chance that there is something deeper. How about spending five minutes emailing the author of the vuln report, explaining why it doesn't appear to be a vulnerability, then asking if there is anything deeper?

It's also crazy to spend a day or two filling out TPS reports on a crank vulnerability alert.

If an organization takes security seriously then it should spend increasing amounts of time on increasingly plausible vulnerability reports.

If you really wanted to attack their vuln-investigation processes, you would simply let them conduct business as usual since it seems they don't know how to triage potential vulnerabilities. If you force the issue by conducting a DDoS, they will respond by developing a better triage system that de-prioritizes crank vuln reports more quickly. Not only will this defeat your DDoS attempt, but it will make them more effective at handling vuln reports going forward.

And from the HN article "intellectual honesty requires bending-over-backwards to provide any evidence that you might be wrong."

The article is so close to a direct Feynman quote that it makes me wonder if the author was subconsciously plagiarizing Feynman. Normally, I wouldn't mind (subconscious plagiarism is everywhere). But in an article about intellectual honesty I would expect the author to "bend over backwards" to identify and declare potential sources of plagiarism. ;-)

The problem with the Python documentation is that it does not adequately explain the value of it's more obscure features (such as coroutines). And since coroutines are obscure in general, programmers won't even know how to appreciate them once they find them (say in PEP-0342 http://www.python.org/dev/peps/pep-0342/).

Posting articles such as this one is very helpful because it pushes useful esoteric knowledge into our consciousness. HN is particularly suited because the community's up-votes convince us that our time will be well spent looking into such articles.

New business idea: Setup proxies in Switzerland. Customers pay a subscription to download pirated content from their Swiss account. From there, you can transfer the customer's data to their home account in the US (or wherever). Seem perfectly legal to me. For extra value added you can do AV and other quality control to make help customers find and safely download pirated content.

I wonder if Switzerland foresaw such businesses...

My first impression was that the combination of lossy compression and transparency would give WebP better traction (because before designers would have to choose between JPEG and PNG for those features). But lossy compression is mainly useful for photos, and transparency is mainly useful for graphic art. How often would a designer want to apply lossy compression to graphic art? How much would would lossy compression compress graphic art anyway?

Now I'm thinking that the combination of lossy compression and transparency will mainly be useful for adding transparency to photos (as demoed in the article).

ADHD is not all bad 15 years ago

For hackers, the best thing about ADHD is hyperfocus, which is a lesser-known, but common symptom of ADHD. Hyperfocus is the tendency "to focus very intently. [...] At times, the focus is so strong that they become oblivious to the world around them." http://www.additudemag.com/adhd/article/612.html

Like when you happily program for 12 hours straight, forgetting to eat lunch and dinner. Sound familiar?

Depends on your definition of ethics. * Consequentialism ethics: make sure the benefits to users outweighs the harm to them (in your judgment) * Deontological ethics: do the morally right thing (for some definition of morally right) * Or pick some other ethical theory

Pragmatically, you want users and prospective users to feel that you are being ethical (assuming they know what your app is up to). Technical people often have a hard time putting themselves in the user's shoes (when users are non-technical). Just pitch your idea to some non-technical friends and ask them if your plan sounds "ethical."

"Proof" as in mathematical proof. As in, it proves a particular mathematical model of the universe is consistent---but says nothing empirically about the actual universe. Am I missing something?

Agreed. Employers compensate you based on their estimate of your __future__ contributions to profit. Asking for compensation during a fire sale is not negotiating; it is begging.

These results are unsurprising to me. But then again, my startup is building a cloud-based mobile-malware detection service to address the inherent limitations of anti-virus on mobile devices. :-)

Here's the problem: "Anti-virus" in general is limited because it relies on static signatures. Therefore it can only detect known malware and is vulnerable to evasion (polymorphism / metamorphism). On mobile devices AV is even more limited because of resource constraints (namely, limited battery and cpu).

By doing malware detection in the cloud, we have plentiful resources to do heavyweight analyses. We also get a better overall detection capability by using behavioral analyses instead of just static signatures (we actually run the apps).

If you're curious about the technical details, we presented at Black Hat in August. https://media.blackhat.com/bh-us-11/Daswani/BH_US_11_Daswani...

P.S. We’re hiring :-)

The author is falling victim to the Confirmation Bias. There are only two experiments, yet the author is content to over-generalize and conclude that "no matter what price we choose, we always make the same revenue." Why not reduce the price 3/4? Increase it by 50%? Increase it by a 100%?

The main point of the Pastebin rant is the claim that Mongo's development standards are insufficient for mission-critical software (such as databases).

So I looked through Mongo's change logs and one of the first things I saw for version 2.0.0 is a "huge" issue: "reIndex() on secondary drops all indexes" https://jira.mongodb.org/browse/SERVER-3866

This sounds like a bad bug for a database to have. And in this article 10gen president says that data loss hasn't been a problem since 1.8, which seems to contradict their own change log....

This gets into the whole "security through obscurity" thing. Ideally, you should use a password-generation system such that if the attacker knows your pasword-generation system (e.g. lines from songs) it would still be infeasible to guess your actual password.

Thats why the 4-random-words technique is good. According to XKCD, the 4-random-words technique generates about 17 trillion passwords---all equally likely.

But even with a long tail, song-lyric passwords relies on obscurity. I imagine there are much fewer than 17 trillion songs to choose from. And if the attacker knew some information about you (say from looking at your Facebook profile or your search history) I'm sure it could drastically weed out the search space.