Yes. We* are doing this full time during regular work hours. But this is not, yet, a product that deserves to be tied to the Google brand. It is just some code and some design documents, and hopes and dreams :)
It could fail. And even if it succeeds, it isn't ever going to be a "product", but a Web Platform feature.
I'm glad you're enthusiastic! But just to set realistic expectations: "this is less about proposing an API, and more about starting a conversation" (https://github.com/chromium/ballista). There is no guarantee that this project will go ahead, even within Chromium/Chrome.
We aren't going to standardize first, then expect buy-in from other browser vendors. We expect to have a discussion (with the web community, including web developers and browser vendors), and from there either jointly standardize/implement, or not. We won't commit to this in Chrome unless we get cooperation from the web community.
This is not a spare-time project. It is being developed at Google by the Chromium team, but it is not an official product, just an experiment. (The disclaimer there is standard boilerplate for open source code.)
More importantly, the plugin does not even run unless you opt in to hotwording (by checking the check box in settings). The open source Chromium code makes sure of this. So you do not need to take our word for it.
Furthermore, you are right that if you turn on the "Ok Google" setting, the plugin will start listening to your microphone, but will not send audio to Google servers unless it hears an "Ok Google".
We probably could delay it until the setting is enabled. I wasn't on the team when that decision was made, but I would imagine it's because a) latency (we want the feature to be enabled right away when you turn it on), and b) just the way it happened and nobody really thought much about it at the time.
The fact is that an end user should not care if software downloads a "binary blob" without running it. This is functionally equivalent to downloading anything from the Internet, a JPG file for example. Chromium downloads a bunch of things on startup, and nobody seems to mind. Just because hotword.nexe happens to be an executable blob doesn't really make a difference.
Hi, I'm an engineer from Google responsible for the hotword module.
I understand the concern that a proprietary component may be performing unknown instructions, and indeed Chromium does download hotword-x86-64.nexe on startup, but it has been carefully designed as an opt-in feature. If you do not turn on "Enable "Ok Google" to start a voice search" (in chrome://settings), Chromium will not run the plugin. You do not need to trust Google engineers to tell you this; the open source Chromium code has the logic to decide whether to run the plugin.
I have posted a detailed response (including the link to the place in the Chromium source code where the module gets run) on our bug tracker at http://crbug.com/500922#c6.
1. This is a research project. It doesn't have any support and if there are future versions, they might change the language in backwards-incompatible ways (but I will generally follow proper practices and bump the major version number in that case).
2. I am reaching the end of my PhD and I don't anticipate spending a lot of, if any, time working on Mars.
I think if you were to play with it a bit, you would start to realise how primitive the language actually is ;)
Sorry to disappoint you. Having said that, the source code is fully available and GPL, so there is no technical or legal reason why you can't use it in any way you like.
You make an interesting point. I haven't decided if I agree with you, but here are my thoughts.
If I understand you, you're saying that x.v should have type Num, but x.u should have type Maybe(Num) (because u is not totally covered). That sounds like a very bad thing, because it means that if I were to change the type so that u is covered, by changing Y to:
Y(u :: Num, v :: Num)
then suddenly everywhere I refer to x.u would break, because x.u would now have type Num, not Maybe(Num).
If I was to go for the "safe" option, it would have to be that all fields return a Maybe no matter what (and I think that would make fields quite unpleasant to use).
I think a better plan (which I've designed but didn't implement -- and I realise that now executing this plan would require a backwards incompatible version of the language) would be to do a simple static analysis of switch statements which records exactly which constructors a variable might have at any given program point, and make it a compile-time error to access a field of a variable unless it is provable that the variable has that field.
So in general, x.u would be a compile error. But this code would be legal, and never generate a runtime error:
switch x:
case X:
whatever(x.u)
You could also do error checking up front to avoid nesting your code too much:
switch x:
case Y:
error("blah")
# Guaranteed to have a 'u'.
whatever(x.u)
(For the record, I actually didn't blindly copy Haskell's semantics in this instance; I came up with this scheme myself and then only later discovered that Haskell had the exact same scheme!)
(Author of the article here). I think you underestimate the power of a good (long) password. Check this out: https://www.grc.com/haystack.htm
That site lets you enter a password and see how long it would take to crack using a brute-force scenario. Assange's 58-character password would apparently take "16.40 million trillion trillion trillion trillion trillion trillion trillion centuries", assuming one hundred trillion guesses per second (which is far more computing power than is presently available to anybody in the world).
Cryptography relies on strong passwords. Assuming that the password wasn't deliberately given out, a 58-character password is going to be secure for a very very long time.
It could fail. And even if it succeeds, it isn't ever going to be a "product", but a Web Platform feature.
*Note: I am the person leading this project.