|
This (or similar technologies) along with several other layers will be the norm in the future. Many have pointed out the short comings of this approach, but short comings are part of every approach to varying degree.
I would think that in order to properly profile a voice for use as one of these layers would require much more than saying a simple phrase multiple times. The AI engine behind it would need to have a much broader and deeper understanding of your voice to approach something reasonably secure.
First off I would think that random phrases would be given to the user to say each time they logged into a system. That way someone couldn't simply record a voice to mimic the user. They then might have a recording but it wouldn't have the right phrase and not pass the check.
But, regardless of how this is or isn't implemented this is only one layer and I fairly confidant that down the road we will be forced to use multi factors with regularity and these factors will be integrated with each other to increase the confidence that the user is who the user says they are.
|
|
|
|
|
Your concerns are valid. Any system relying on just one spoofable mode of authentication is leaving themselves open to the threat of impersonation and all the vulnerabilities it entails.
How hard is it to stand near someone and watch while they pay for a purchase with their smart card (debit, credit or otherwise) and enter a 4-digit PIN?
Is mere possession of the card and a PIN sufficient authorization protection?
I don't. And yet we have lived with this scheme for a long time now.
Multi-modal authentication is the future.
Most personal devices have microphones and cameras now. These combined can provide simultaneous live biometric capture; combining, say, facial geometry, iris pattern, and voice recognition, eventually c/w verification that they person in front of the microphone is moving their lips in a manner concomitant with what on-the-spot-unique phrase is being said.
Current vendor-supplied payment devices can also be upgraded with cameras and microphones.
We will get there. It's only a matter of time.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
I was going to comment on this, but decide to remain mute.
|
|
|
|
|
Someone in the office mentioned that office265.com will redirect to office365.com. So i was wondering how many domains does microsoft own to protect wrongly typed address?
|
|
|
|
|
|
None... all goes here: https://products.office.com
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
When a line like
string Desc = "";
causes a system.indexoutofrangeexception error, I tend to shut VS down and go do something else.
|
|
|
|
|
It seems to be mutual 
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
It's because you used PascalCasing while variables should be camelCased and you should use string.Empty for empty strings
|
|
|
|
|
Sander Rossel wrote: should be camelCased
Sander Rossel wrote: should use string.Empty
The universe does not care. The compiler does not care. I usually also don't care.
But then Mr. Knowitall pops up and tells you what you should do. 
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Good programmers DO care about their code, guidelines and best practices though
The camelCasing is just a preference (although widely accepted), I agree.
But using string.Empty instead of "" is actually a useful memory optimization!
|
|
|
|
|
Sander Rossel wrote: But using string.Empty instead of "" is actually a useful memory optimization!
The compiler actually deals with that automatically, as I have heard. If not, giving the compiler a little help to do it right is absolutely fine, as long as you know why you are doing this.
The only thing I don't like is cargo cult[^] programmers. Their list of rules and conventions is miles long and constantly growing and they can recite any of them at any time. They also never have a clue why they are doing this.
"Guru XXX said so."
"So what? He says a lot."
"It's a design pattern."
"Singleton? Some actually think it's an antipattern. Don't you have some nice rules about globals?"
"Then it must be a convention!"
"A convention that regulates a question of architecture? Who made that convention for us?"
I have really had that conversation. You can easily convince me of almost anything (even using global variables or goto) if you can give me a good reason, but please spare me your personal bible of rules and conventions.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Completely agreed with you on that one. 
|
|
|
|
|
CDP1802 wrote: You can easily convince me of almost anything (even using global variables or goto) if you can give me a good reason, but please spare me your personal bible of rules and conventions.
100% with you on that.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Actually there is no such optimization...
This:
string s1 = "";
string s2 = string.Empty;
Will compile to this:
IL_0001: ldstr ""
IL_0006: stloc.0
IL_0007: ldsfld string [mscorlib]System.String::Empty
IL_000c: stloc.1
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Too bad. It would have been really useful. What does the disassembly after the JIT is finished look like?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
There you go!
string s1 = ""
00352D49 mov eax,dword ptr ds:[32522C0h]
00352D4F mov dword ptr [ebp-40h],eax
string s2 = string.Empty
00352D52 mov eax,dword ptr ds:[32522C0h]
00352D58 mov dword ptr [ebp-44h],eax
However it would be time-saving to optimize it while compiling...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Well, at least we have this. Now I wonder if that also works with any string constant you define and literal strings.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Strings (constants) has a queue (poll?) to save space...
IL_0001: ldstr "CDP1802"
IL_0006: stloc.0
IL_0007: ldstr "CDP1802"
IL_000c: stloc.1
string s1 = "CDP1802"
001D2DD1 mov eax,dword ptr ds:[30D232Ch]
001D2DD7 mov dword ptr [ebp-40h],eax
string s2 = "CDP1802"
001D2DDA mov eax,dword ptr ds:[30D232Ch]
001D2DE0 mov dword ptr [ebp-44h],eax
Still a JIT optimization...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: Still a JIT optimization...
That makes sense, like the old C/C++ compilers, it strips away all high level language features and cuts some corners.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Yeah, I'm totally with you.
Throughout my career I've worked with people who thought all code should look the same no matter who wrote it.
(Real life) example:
"We don't do interfaces here."
"But... That's just good and common practice!"
"All code must look the same so you can't just go and make an interface because we will know you wrote it."
I'm all for change and discussion.
If something is good let's do it, if something is not then don't.
That's how we can learn from each other.
I think the best argument for guidelines is that some programmers aren't all that great and make the worst code ever if they don't have some guidelines.
We have the guideline "functions can't be over 20 lines", an arbitrary number, to prevent people from writing 1000 line functions (yes, literally) 
Our code improved since we talked about it and agreed on the guideline (they're still larger than 20, but at least not 1000) 
|
|
|
|
|
Of course we can't all simply do what we like if we want our work to fit together, but no bloated rulebook with (literally) hundreds of 'rules' and 'conventions' for and against everything, plus 'code reviews' which do little more than nitpicking over these rules (with different interpretations of the rules, depending on the reviewer) and endless discussions about some new rules which someone wants to add, just to cover some more special cases.
I have been in a place where they really went overboard with this and we were going nowhere mighty fast. Despite all the time and work put into this, the code was still as disfunctional as before. There were too many fundamental flaws that no obscession with 'cosmetics' could ever solve. As if lipstick on a pig ever solved anything.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
CDP1802 wrote: As if lipstick on a pig ever solved anything.
So long in business and don't know yet, that you should use silk on a monkey?
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Sander Rossel wrote: But using string.Empty instead of "" is actually a useful memory optimization!
If it were the case, I'd prefer to waste some memory and have readable code.
Your brain processes "" faster than string.Empty.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Sander Rossel wrote: But using string.Empty instead of "" is actually a useful memory optimization!
It does not have effect on memory consumption due to string interning.
The main reason I use string.Empty is that var foo = "" looks ugly to me.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
