skysight-inc/HackerNews huggingface dataset:
From the Broad's press release, on how the new system is different[1]:

"The newly described Cpf1 system differs in several important ways from the previously described Cas9, with significant implications for research and therapeutics, as well as for business and intellectual property:

First: In its natural form, the DNA-cutting enzyme Cas9 forms a complex with two small RNAs, both of which are required for the cutting activity. The Cpf1 system is simpler in that it requires only a single RNA. The Cpf1 enzyme is also smaller than the standard SpCas9, making it easier to deliver into cells and tissues.

Second, and perhaps most significantly: Cpf1 cuts DNA in a different manner than Cas9. When the Cas9 complex cuts DNA, it cuts both strands at the same place, leaving ‘blunt ends’ that often undergo mutations as they are rejoined. With the Cpf1 complex the cuts in the two strands are offset, leaving short overhangs on the exposed ends. This is expected to help with precise insertion, allowing researchers to integrate a piece of DNA more efficiently and accurately.

Third: Cpf1 cuts far away from the recognition site, meaning that even if the targeted gene becomes mutated at the cut site, it can likely still be re-cut, allowing multiple opportunities for correct editing to occur.

Fourth: the Cpf1 system provides new flexibility in choosing target sites. Like Cas9, the Cpf1 complex must first attach to a short sequence known as a PAM, and targets must be chosen that are adjacent to naturally occurring PAM sequences. The Cpf1 complex recognizes very different PAM sequences from those of Cas9. This could be an advantage in targeting some genomes, such as in the malaria parasite as well as in humans."

1. https://www.broadinstitute.org/news/7272
Exactly. A better, or at least more general, mitigation than enabling HSTS (though that's a good idea anyway), is to not design your web application in such a way that a modified cookie in the client creates a vulnerability. Since cookies are stored in the client, they are always going to be susceptible to malware on the user's machine. So, trusting that the contents of a cookie were authored by the service receiving them is a bad idea in general. Cookies should be stored along with some additional information that verifies their authorship.

A relatively simple way to accomplish this is to have your application include an HMAC in the cookie contents, and verify it whenever the cookie is received. e.g, if you are storing $session_id in a cookie, change your cookie contents to be "$session_id:$hmac_of_session_id", and verify the HMAC every time a cookie is presented.

Now a user, or malware, or a MITM, is not in the position to take over or modify a different user's session simply by altering the cookie, since they will not be able to produce a valid HMAC (the key is never shared with the user).

If even storing the key in your web frontends is too risky, you could use RSA or DSA signatures, only store the public key in the web frontend that verifies cookies, and store the private key in a more hardened cookie-signing service that isn't directly exposed to external networks. This service can be invoked when new sessions are created or upon user login, if applicable.

On top of this, if the client supports ChannelID, you should include the ChannelID in the message that is HMAC'd, so that stolen cookies cannot be reused on other machines.
Link is broken; actual URL is http://www.math.harvard.edu/~mazur/preprints/when_is_one.pdf
Twitch is still Flash, though the interface has been converted to HTML+JS.

http://blog.twitch.tv/2015/07/video-player-controls-now-in-h...
Seems like they are getting close. But some issues:

- Not yet Human level accuracy even for the clean speech.

- Vocabulary limit is still an issue (but they are much better than before)

- Recognition under very noisy environments.

- Recognition in the existence of multiple overlapping voices

- Heavy accents.

- Spontaneous speech.

- Languages other than English are also not in the same level.
... and given that Ackerly was first in IAD working on cross-domain solutions and then SNIP, I doubt he is an expert on encryption.

What do you think of Virtru? I was hoping you would comment on this article since you're an actual crypto expert.

Encryption-by-plugin seems less bad than encryption-by-javascript, but their entire business model depends on us trusting Virtru for key escrow. This doesn't seem any better than trusting Apple for iMessage or Google for Gmail. Am I missing anything?

Edit: I guess a malicious attacker would need to take two steps for the information. One for the encryption key hosted at Virtru, then a second step to actually capture the emailed message.
Elixir and Lua are among the few relevant contributions to the computer science field originating from my country
(Brazil).
Since all I've worked on for the last three years is the infrastructure, and not the binary that lands on your desktop/phone, I'm not really qualified to answer that. (Which is just a fancy way of saying I've got no earthly idea :))

But since I've seen @bengoodger in this thread, maybe he can answer your questions.
VIDEO: CONSUMER PROPOSAL VS. PERSONAL BANKRUPTCY
We're talking about extracting packages in a one-off, unsupported configuration that literally nobody does, not using them as intended, so 90% of those things you mentioned are off the table.
Indeed. Another example:

https://www.ftc.gov/news-events/press-releases/2014/11/ftc-i...

The FTC fines seem to be quite affordable to these players, who may just see them as a minor cost of doing business. Sensa for example had sales of $300m, fines of $26m. The example above has annual sales of around $250m. The profit margins on the sales numbers for these kinds of products are very high too.
their valuation tool is kind of absurd.
It's definitely feature, not flaw; think of all the lost revenue from merchants/acquirers/issuers/associations/etc when a card needs to be legitimately replaced (e.g. updating your Netflix subscription is the last thing on your mind if you lost your wallet). Full disclosure: currently working on a product that does this very thing.
Subways dont offer much privacy. How many pods are you going to have to report for smelling like sex before you can find a clean one on Monday morning?
how chromium works after google jumped in: ignoring users and maximizing google monetization.

e.g. https://code.google.com/p/chromium/issues/detail?id=84177

(i also tried to find all the commits or issues where all the 3 ways to disable sending referrer headers were removed over time, but obviously, there are no issues and the commits are probably mixed up with other things)
When people developped Rust or Go, did they say "this is a C", or "This is newC"? They said: "this is new language with a C-like syntax with such and such features". Why not be precise?
This was my first reaction too, but I took the time to read through most of the paper. The end result is that someone visiting "unsecure.com" means they can no longer trust Gmail's chat interface. That's pretty obviously a vulnerability.

True, it's more of an issue with web apps themselves and not using HSTS.

Perhaps the real problem is the terrible clickbait title. The actual authors had much better sense and taste: "Cookies Lack Integrity: Real-World Implications". Perhaps HN mods could change it.
That's it, thanks!

For anyone wanting to read the paper itself, the link the imore.com article is broken. Use this one instead: http://www.usenix.org/system/files/conference/usenixsecurity...
That's interesting feedback, Ian. Funny, though - some say we charge WAY too much while others say we don't charge enough. Why do you think we're on the high end of the scale. (And, if that's the case, you'd definitely consider SELLING your sites with us, right?)
The time I am committing to a company is in the hours per week that I am paid to work. There's 168 hours in a week, if you're not paying me for all of them, I can do what I like in the remaining time.

Dedicating your whole waking life to a company is plain stupid.
Dave McClure – Startup Metrics for Pirates: AARRR (2007)
What you describe takes CONSIDERABLE time and money on the front end that start-ups don't have. Ok, but lets assume they do and they land a contract.

The FAR isn't just some document that you read and understand - there is an entire additional process for diligence and documentation that goes along with it.

Now you need 60 days of deliverables until you get paid from the government.

CACI and the rest of the major Prime contractors have hundreds of contract officers that work and maintain these contracts - often outnumbering the actual developers of whatever the products are.

What needs to change is the FAR and the budgeting process. Until then we will continue to ignore the government.
I've carried out that alteration/redlining in every tech work contract I've signed. It has never been a blocking issue, and it is usually the case that the people handling the details of hiring are unaware of the details of the clauses in the contract - they just take what the lawyers hand over as boilerplate.

https://www.exratione.com/2011/11/the-miserable-state-of-int...
Congratulations to the Virtru team for your success! I remember in 2012 when 2 of the guys were working on a cryptographic binding contract and left to join this startup.
If I'm at home, on my own computer, on my own time, I am not "working for them".
Chaos Engineering Upgraded
It isn't that bad of a problem. Green roofs are becoming very common. It is just about the depth of the soil, the selection of the correct plants and usually some type of plastic barrier.
> Both of these are easily biased.

Indeed. But remedies exist. Statisticians can examine the validity of the data, analysts and detectives can be trained to interpret the results correctly, and social scientists can point out the dangers of relying solely on computer systems.

I have no strong view for or against breathalysers. I'll concede that there may be some errors in those tests. Does that completely invalidate these tools in judging if someone is too drunk to drive and may cause harm to self or others? Should we only opt for rigorous methods like drawing blood samples? My view is: no, we should not. These are valuable tools that work for the large majority of times and help save lives (at the inevitable cost of some errors and inconvenience).

In my world I believe in just intentions. Breathalysers are not introduced to imprison sober drivers, they are to combat drunk ("lazy, incompetent or malicious") drivers on our roads.

These methods are useful for catching the savvy criminals too. I am not ignoring that these systems are also useful to target activists and political dissidents. That's basically what they were build for in the first place (well, that and the terrorists, see DARPA LifeLog). It's just now that these tools are adopted by local Police departments.

A weapon stick can be used to subdue a suspect through non-lethal force, and it can be used to choke a peaceful protester. It will succeed in both tasks. It's not a stupid ineffective tool we should take away, because it can be used in bad ways. We should make sure to avoid the bad usage, and provide police with the best weapon stick possible for the good usage.

You assume that this system will be used to justify police brutality and that this system will be used by people who think that any black person is a "criminal". I have a higher opinion of the people who join the police. I rather reserve such judgment to the criminals themselves.
He has also revised his opinion on the matter earlier today:

https://www.washingtonpost.com/news/volokh-conspiracy/wp/201...
> They seem to have done a lot of things right''

This is because Elixir is "just" a different syntax for Erlang/OTP which is used in very mission critical software in real world (it was originally created for telephone systems)
Here are some odd-ball, low-skilled ideas for making cash on the side from Dan Miller > http://www.48days.com/wp-content/uploads/free_documents/48bu...
I think of the following:

- store only session ID in cookie

- regenerate session ID upon privilege escalation (login, what else?)

- destroy session upon logout

That being the case, is this really capable of doing much damage? Especially once you enable HSTS.
I don't think full time means 24hrs/day as that would be against labor laws!

Also if a developer is earning 100K it would amount to $11.5/hr.
> A scenario I've seen play out multiple times:

The salient details your scenario omits:

1. A lot of employees create side projects related to their employer's business and/or R&D activities. These are not subject to 2870's protections.

2. A lot of employees make the mistake of working on the side project during work hours or using their employer's equipment. Most employees who get caught up in these types of disputes claim they didn't work on the side project during work hours or using the employer's equipment but far fewer can make it through discovery with such a claim intact. There really is no wiggle room on this and one slip up can spell doom.

> We saw this just the other day on HN.

Assuming you're referring to Shred, no, we didn't. The matter there does not relate to a side project, although you can be sure that Smule will use discovery to look for evidence that its former employees were working on their idea before they left its employ.

You can read the actual claims at http://webaccess.sftc.org/Scripts/Magic94/mgrqispi94.dll?APP....

> Best thing to do: no side projects.

This is the best advice as far as side projects with commercial ambition or potential are concerned.
Is that the same Taliban that was trained and funded by the west to fight the USSR? Sounds awfully similar to the situation in Syria.

Edit: this is so far off topic that I regret posting it, but I don't like deleting things and will leave it in place. Can we get back to talking about Pluto?
The wonderful world of distributed systems and metadata management
Amazon Echo Competitor
#1 is the real killer. If you work for the Googles / Apples / Facebooks of the world, basically anything involving computers is going to fall under "actual or demonstrably anticipated research or development of the employer"
VU#804060 is talking about "cookie forcing". This is not a new discovery. Here's Chris Evans (not the actor) talking about it in 2008: http://scarybeastsecurity.blogspot.com/2008/11/cookie-forcin...

The best solution is to preload HSTS on a domain and include all subdomains, and we've been saying that for years. That prevents any HTTP connections, although it's obviously not an easy solution in many cases.

The USENIX paper does suggest some unilateral changes to cookie semantics to address this issue, but any such changes have eye-watering compatibility concerns and could only be deployed after a lot of testing.
We'll call it a terse highbrow dismissal, then.

My terse highbrow dismissal: separating the programming environment from the protocol results in serious, pragmatic problems. For instance: protocols specified in English, in which messages are validated by hand and not by a type system.
The difference is described here in Orin Kerrs reversal of his opinion earlier today:

https://www.washingtonpost.com/news/volokh-conspiracy/wp/201...

Basically, having to provide something in your mind, the passcode, is testimony, a finger print, much like a key, is not testimony.
Sure, but I would transfer most of it out to USD.

I enjoy BTC for sending/receiving payments as it is very easy, but I don't see it as a safe 'investment'.
I just asked Google about the weather in my city tomorrow and it said it doesn't know any city named "Banana".

So no, it's certanly not a solved problem, especially if you want to use that kind of functionality outside the few english speaking countries.
Previous discussion: https://news.ycombinator.com/item?id=10277024
heh, don't confuse the readers
He has reversed his opinion on the matter earlier today:

https://www.washingtonpost.com/news/volokh-conspiracy/wp/201...
I'm not exactly unbiased to Urbit, but I found Hoon as usable as they say it is. It seems like everyone that hears about Hoon's rune syntax comments about how insane it is, but it really is easy to get into.

I'm partial to calling it "Chinese Lisp" - Hoon runes are converted directly into AST nodes, but instead of using friendly words it uses weird diagraphs. The fact that the runes are grouped into families makes it much simply, however. You don't have to know what "|*" does exactly, just know that all runes that start with bar (|) create the equivalent of functions, so it has to be related to that. Instead of memorizing 100+ runes that are all completely different from eachother, most of them are just variants of others and are even macros to other runes.

While it may look like garbage, programs such as a brainfuck vm[1] are easy to scan when you can get the gist of the program structure very easily.

While some of the names are quite a pain, a good portion of the stdlib's arms are teniously named related to their subject, or are very easily grouped with their function. snag is index, scag is prefix, slag is suffix.[2] The docs for the stdlib, along with examples of how to use it, are shipped with every planet at http://localhost:8080/home/tree/pub/doc/hoon/library, although the initial page generation takes a bit. I'm not that big of a fan of the CVC variable names, however.

1: https://raw.githubusercontent.com/chc4/sample-apps/master/bf...
2: http://doznec.urbit.org/home/tree/pub/doc/hoon/library/2b#-s...
to be fair though, lisp is about a lot more than just its syntax
What I am praising is the fact they listened to their customer feedback, and came back with a plan that they feel is "better" and addresses many of the issues their customers had.

I am not sure what you mean by "doing the thing they should have done in the first place", What was the thing "they should have done"?

They did their own market analysis, they did what they thought was right at the time, their userbase disagreed, they incorporated feedback and adjusted.

This is exactly what I want companies I support to do.

If you are mad at them for not reading your mind as to how you want them to run their business, that seems a bit silly.
It seems like a fairly reasonable compromise that addresses the concerns of both parties -- JetBrains needs a recurring revenue stream to support updates (fixes to version at time of purchase/subscription) and upgrades (new versions), while the customer needs the right to continue to use the software they purchased.

Yes, the customer doesn't get to keep the latest version if they stop their subscription, but JetBrains needs some reasonable hook to cover support costs, and quite frankly, their software is relatively cheap in the commercial market and generally works as expected.

It also addresses the concerns of those who claim "they'd be willing to pay more". If you decide to stop your update subscription, you have the option of getting a perpetual license for the latest version at that point by simply buying a year's worth of updates.

If there's a better option that keeps JetBrains in business and customers happy, I'm sure many would like to hear it.
That's a good point. Gasoline engines have come a long way since the days of magneto operation, with variable timing, ignition, and direct injection (of which some piston driven aircraft may already use). Turboprops and turbofans (jets) are already very efficient compared to automotive piston engine aircraft. A 747 for instance gets around 91 mpg/person while buses average around 200 mpg/person - but, the drag forces on an aircraft are I think at least an order of magnitude greater.
I doubt they have 400 people dedicated to the iOS app. I think it's more that 400 people happened to have touched the iOS app.
The memory management scheme is very novel: http://www.newlisp.org/MemoryManagement.html I don't get how it can work since it would require most objects to be passed by value and not reference.
Sunday's Lunar Eclipse Has Got It All: The Two-Way
I'm just going to list all of my criticisms after reading what's on the website:

1. Treating functions as lists effectively makes this a weakly typed language like C, whereas both Scheme and Common Lisp are both strong.

2. What advantage does having implicit function arguments (using nil if not provided, not default arguments) have at all unless if you just hate type safety and would prefer unreliable software? There are lots of other ways to maintain type safety while eliding runtime type checks in hot loops.

3. Changing the binding time for free variables within a closure would also imply that a binding by that name must be in scope at the time the function is called, no? This sounds like dynamic scoping... which is known to be difficult to use and error prone. Do you just assume 'nil' when no binding exists?
So, engineers work on the master branch, test locally and push to master? And the buildbot detects commits that break the build after the fact?
That list of languages was "popular" rather than "shitty and slow", although some of them certainly are shitty (and dynamic languages do tend to be kinda slow). I realize my phrasing was confusing.
> business model

Extortion isn't a business model.
You can find a lot of disagreement in the google groups thread linked. Erik Naggum, Ron Garret (posting as Erann Gat), and Kent Pitman show up. Naggum as usual penetrates the usual back-and-forth with a stimulating meta-argument.

https://groups.google.com/forum/#!topic/comp.lang.lisp/Bj8Hx...

I've pasted some text from that thread. I pasted reasons not because of their quality, but to show that there were people passionate about the distinction.

> at the Lisp & Functional Programming conference, there was
serious difficulty getting Lisp papers accepted. Lisp papers were
about engineering, and Scheme papers were about mathy and theoretical
issues. And, to be utterly crude about it, what I think gets papers
accepted to such conferences is heavy use of greek letters

> a scheme program is defined as
a string of characters whereas a CL program is defined as a sequence
of lists of Lisp objects. This may seem pedantic or trivial but a lot
of different design decisions follow from this. It makes Scheme an
infix member of the Algol language family.

> The Scheme community has evolved a set of values at
odds with the spirit of Lisp: the goal for simplicity at the expense
of convenience (compare the concept of CL's $item designators with the
design of convert stuff explicitly like Scheme's exact->inexact), the
goal of only giving basic blocks and letting you assemble stuff
yourself (call/cc isn't a replacement for a worked out exception
system).

> I think it's a small group of insecure Scheme users who think that
they should be considered "A Lisp" so that they get all the
"publicity" that Lisp does along with the publicity that Scheme does.

> What those Schemers get from defaming Lisp beats me. Probaby some sort
of jealous envy.
Here's some good reading. Looks like they can't irrefutably establish a hidden volume's presence, but there are lots of clues nonetheless.

http://security.stackexchange.com/questions/9058/is-it-possi...
I think that is just a technology showcase that this technique is so good that for some small-mid size pronunciation dictionary, it can work quite well without using a language model. Similar works were reported recently (ASR systems without language models or with character models). But seems like real system is still using a graph generated with a language model and context dependent phones.