This article is a joke, Hard to copy do to button placement? really? I see no more room under the home button than the others and how hard is it to move a button up or make the phone taller. They redesign these phones from scratch every 6 months-1yr.
With how phones are held it would be better to have it on the side or back.
Apple will never put it on the front of their beautiful phone, if they were going to do that they would have by now, this tech has been around a long time, there most be a newer better version of it that they will be the first to have or put it on one of the sides, even if it screws the case people.
Additionally you don;t need this to replace passwords, you need it to protect the passwords stored in the phone, it can start there and then branch out to the actual apps, if the phone locks itself one entry point will work just fine.
1. Charlie Miller, a well known hacker, has hacked NFC phones, and it's been in the process of getting patched, but not all phones have been patched.
Whenever someone repeats this myth that NFC was hacked, I cringe. Miller didn't hack anything.
All he did was point out that you might be able to secretly pass a malicious website's URL via NFC to someone's phone without them noticing you did it. Yeah sure. Okay, let's say you did.
At that point, then the targeted user has to:
Not be surprised or suspicious about why their phone woke up and has a strange website showing.
Look at the website and click on a link.
Agree to the suspicious app download popup.
Go find the downloaded app.
Have app sideloading enabled.
Install the app.
Agree to all its permissions.
Oh wait. This lengthy scenario could happen with suspicious MMS and email, too. It really has little to do with NFC, and absolutely NOTHING to do with NFC payments.
The device can provide the button with it's public key to encrypt data to send to the device.
That would certainly save the button having its own key but I was thinking of the scenario where someone steals your print data. If the phone sends the button the public key and they have the source data, they just take the public key, encrypt the source and send it back to unlock. If the button had the key embedded, a thief would have to physically hack every button for every phone to recreate the response but as I say, that makes it very problematic if the sensor is somehow replaced in the phone e.g by a broken home button.
It depends on what exploits/scenarios are being prevented. Obviously if someone gets an OS exploit, you pretty much have what you want anyway. But if there was a mass remote exploit that intercepted the sensor data from a lot of phones, it could be shared online and phone thieves could then run that database to unlock stolen phones.
I'm sure they've tested loads of methods to see what can be bypassed so it'll be sufficiently secure but it can't be impervious to some form of bypass. At the end of the day, every security system involves verifying a piece of data. This piece of data:
- has to be hard to get hold of by a 3rd party
- has to be convenient to get hold of by the user
- has to be unique so it can't be guessed or subjected to a mass exploit
It's very difficult to find a piece of data that satisfies all of those conditions because during any verification step, the user has to present the data. An exploit is easy once it's intercepted and if you can't change the piece of data, it makes future exploits easier.
Lenovo laptops have had fingerprint sensors built in for the past 7 or 8 years, and they range on any given day from great to terrible and frustrating, depending on how finicky the sensor and or software can be, to how sweaty your hands are, to if you've got a scratch on your finger, to the relative humidity in the room you're in.
The tech Apple bought (TruePrint) is supposed to scan under the skin to avoid that. It says it detects a pulse too so it would be harder to use a fake finger. There were tests done in 2005 that bypassed one implementation of it:
but they have probably updated the sensor since then to detect the pulse. Manufacturers who use these scanners might find a problem implementing them now that Apple owns the company making the technology.
Well it wouldn't be a button if it was part of the screen. One of it's uses is that it allows blind people to use the phone. It has to be a physical button for that to work.
Um, no. I did not say make it part of the screen. I said make it as a screen like the glass trackpads. So you will have the dedicated button, but it will also act as a mini trackpad/bio reader.
Edited: I guess I see how this is confusing, sorry. So I suggest to make the home button a hybrid of a Home Button, Trackpad, and Biometric reader. This would add so much functionality to this button that awesome would not be a big enough word.
This could be used to scrolling web/email pages as well as, well, anything really. Use it for games as a joystick. Zoom in/out for maps or camera. Same as pinch, but you don't have touch the screen which at time is not as natural. Act out the camera in landscape and work the button to zoom in/out. Feel natural does it not?
I really think that could open up so many options and set the iPhone that much more apart from other phones.
Um, no. I did not say make it part of the screen. I said make it as a screen like the glass trackpads. So you will have the dedicated button, but it will also act as a mini trackpad/bio reader.
Edited: I guess I see how this is confusing, sorry. So I suggest to make the home button a hybrid of a Home Button, Trackpad, and Biometric reader. This would add so much functionality to this button that awesome would not be a big enough word.
This could be used to scrolling web/email pages as well as, well, anything really. Use it for games as a joystick. Zoom in/out for maps or camera. Same as pinch, but you don't have touch the screen which at time is not as natural. Act out the camera in landscape and work the button to zoom in/out. Feel natural does it not?
I really think that could open up so many options and set the iPhone that much more apart from other phones.
If they were to put the sensors for finger print recognition in the home button then all of the possibilities you mentioned are opened up.
I would imagine that Apple could make an iPhone with a larger screen as well because then the whole 1 handed operation argument would be mute if most functions can be done via the home button.
Great, another f#@king App. That's all I want...you totally missed my point. Native man...
After checking out the CardStar app, it appears to be everything passbook was advertised to be but isn't. Physical cards can be uploaded and digital cards can be added all from the app's rich database.
No downloading apps to add passes (which that process I've found to be hit or miss in passbook). And a large database of passes available for upload.
Apple should either learn from CardStar or buy them, but Apple's track record with updating native apps is pretty sketchy. I hope they fix passbook sooner than later but I have my doubts.
They see a future where you authenticate one device — your smartphone or something like a YubiKey — and then use that almost like a car key, to fire up your web mail and online accounts.
In the future, they’d like things to get even easier, perhaps connecting to the computer via wireless technology.
“We’d like your smartphone or smartcard-embedded finger ring to authorize a new computer via a tap on the computer, even in situations in which your phone might be without cellular connectivity,” the Googlers write.
But for Google’s password-liberation plan to really take off, they’re going to need other websites to play ball. “Others have tried similar approaches but achieved little success in the consumer world,” they write. “Although we recognize that our initiative will likewise remain speculative until we’ve proven large scale acceptance, we’re eager to test it with other websites.”
So they’ve developed a (as yet unnamed) protocol for device-based authentication that they say is independent of Google, requires no special software to work — aside from a web browser that supports the login standard — and which prevents web sites from using this technology to track users.
They see a future where you authenticate one device — your smartphone or something like a YubiKey — and then use that almost like a car key, to fire up your web mail and online accounts.
This is really flawed because it makes 3rd party authentication dependent on the issuer:
Someone can hack or DDOS the core servers where everyone's private keys are stored. Google providing the service would be more reliable but I don't want to be blocked from accessing a service because someone else's authentication servers mess up or time out.
Requiring the user to keep special hardware is always going to be problematic and I don't think it's needed. Obviously it's used for payment systems (credit cards etc) but it's not convenient for regular services.
I think the best balance between security and convenience is to use challenge-response authentication and public key cryptography along with renewable and diverse private keys.
A practical example would be:
- sign up to a website and the server asks for a public key
- the device would generate a private key from fingerprint vectors and a random code and create a corresponding public key and sends the public key to the server
- the user device stores the random part of the private key behind a simple authentication
- when a server needs you to login, it just sends a random code encrypted using the public key
- your device decrypts this using both fingerprint and the random part of the private key and sends the decrypted code back for verification
If someone hacks the server, they'll only ever find the public key, which doesn't matter.
If someone challenges the server, they'll be sent an encrypted message, which they can't decode.
If someone intercepts the message, it's encrypted going down and just a random string going back. The connection would usually be over SSL anyway.
If someone spoofs a website, all they can do is send you a random code. They might be able to figure out the private key with a significant number of requests but the device would know to only submit a single response.
If someone steals your device, they have to bypass the local authentication, which can be behind a fingerprint id or passcode or both depending on circumstance. But they still only get half of the private key unless they recreate your finger touching the scanner.
These random parts of the private keys can be transparently or manually synced between devices with a fingerprint authentication and keys can be generated for devices without scanners.
It also means that if someone does recreate your finger authentication, they can't bypass all authentication systems because they still need the random parts of the private keys, which can be renewed and never leave a local device.
All Apple needs to do now is trademark 1-thumb purchasing before Amazon.
Well sorta possible yet did you think it through that it still requires a digital button so home button forever.
The original physical button was necessary because iOS was new, and a simple wired interrupt button was easiest to implement.
Now, with a more robust OS and with the proper drivers, even an onscreen button should work fine. Or if they were still worried, they could even build the interrupt capability into the touchscreen (or touchpad area) controller itself.
Either way, the upshot is that Apple could use a capacitive Home button if they wished.
Side note: It should really be called the "Apps" button, since it goes to a list of apps instead of a traditional phone home page. That's also why Apple placed the image of a blank rounded app icon on it instead of a house.
Now, with a more robust OS and with the proper drivers, even an onscreen button should work fine. Or if they were still worried, they could even build the interrupt capability into the touchscreen (or touchpad area) controller itself.
Good luck with that: except it requires further sandboxing of apps, removing their top-level access to the touchscreen. I can imagine you'll have a few things to say about it when it (doesn't) happen…
Good luck with that: except it requires further sandboxing of apps, removing their top-level access to the touchscreen. I can imagine you'll have a few things to say about it when it (doesn't) happen…
Strange comments.
I'm neither pro nor con about it. I'm just responding to those who want to know if it's technically possible.
The fact is, from an engineering standpoint, there is nothing preventing Apple from using a touch home button if they wished.
Certainly there's no further sandboxing required. Apps don't have direct touchscreen controller access. Only the OS does.
And yet both lock up when one locks up. That's why something in the hierarchy has to change.
You have a good point. That's why I suggested that adding interrupt code to the touchscreen controller (or its port) could be an end solution. That would make it outside of, and immune to, OS problems, just like a physical button.
Tech explanation: Apple uses a standalone touchscreen controller chip, which most likely communicates with the main CPU over an SPI (Serial Peripheral Interface) line. The CPU receiver should have an interrupt that can be fired when the controller sends touch data. Or, they could go further and have TI custom make the controller to have an independent interrupt output that could go to a higher priority CPU interrupt input when the user touches the Home area.
It doesn't matter whether an external interrupt comes from a button or a controller. To the CPU, it's the same thing.
Oops, forgot that readers might not know what an interrupt is. In this case, it's an external wire coming into the CPU that tells it to stop (interrupt) what it's doing and go execute a special section of code (called an interrupt handler). They're used for two main reasons:
2) Efficiency. Old or cheap computers must spend their time constantly polling for inputs. Keyboard scans, disk drive status, serial port in/output, touch, you name it... the CPU wastes its time checking to see if something is happening. Interrupts only happen when some data is ready, which means the CPU only has to handle the input when it's ready, and can spend most of its time doing things for the user instead... or sitting idle to save battery.
1) Robustness. Unless programmed code has turned off or masked an interrupt, the CPU must handle it. (And there's also usually one interrupt that you cannot turn off... that's the reset line.) That's the secret here: even if an app is out of control using up the CPU, firing the signal on the interrupt line will stop whatever that app is doing, and force the CPU to handle the interrupt. That's how they allow for the OS to take control back. (Most embedded computers like in your car have what's called a watchdog timer just for this purpose. No matter how the code fails, that timer is going to cause an interrupt and thus allow the CPU a chance to get back on track.)
Disclosure: I've been programming CPU interrupts since my first 6800 microprocessor kit in 1978. Back then, I had to compile assembly code to hex codes in my head and punch in those digits line by line. Oldtimers here will have "fond" remembrances of doing this.
I hope this isn't true. It would make far more sense to integrate it into the screen.
Especially since they just spent millions buying a company with world-leading technology that does exactly that.
I can see a potential problem with this in that your screen is going to get covered in greasy fingerprints leading to more wiping and irritation. At least in normal touch-screen operation it tends to be the finger-tips used fleetingly rather than the flat of the finger used for longer.
For that reason it would be better to have the finger-print reader off screen.
For that reason it would be better to have the finger-print reader off screen.
Plus, of course, the grease leaves your fingerprint on the screen itself, where a thief could lift it, assuming it was still there and okay.
(However, the better fingerprint recognition code of today also looks for a match to a previous login attempt. Rather than letting you in as you might think, it assumes that a _perfectly exact_ match to a previous login is likely to be a spoofing attempt using a fingerprint copy. The code would rather that each attempt be slightly different in alignment, viewable areas, etc, thus indicating a real finger.)
I can see a potential problem with this in that your screen is going to get covered in greasy fingerprints leading to more wiping and irritation. At least in normal touch-screen operation it tends to be the finger-tips used fleetingly rather than the flat of the finger used for longer.
For that reason it would be better to have the finger-print reader off screen.
And if analyst are right it would give another job to the already overworked home button, and keep Apple ahead of the competition. Somehow.
Comments
With how phones are held it would be better to have it on the side or back.
Apple will never put it on the front of their beautiful phone, if they were going to do that they would have by now, this tech has been around a long time, there most be a newer better version of it that they will be the first to have or put it on one of the sides, even if it screws the case people.
Additionally you don;t need this to replace passwords, you need it to protect the passwords stored in the phone, it can start there and then branch out to the actual apps, if the phone locks itself one entry point will work just fine.
Quote:
Originally Posted by drblank
1. Charlie Miller, a well known hacker, has hacked NFC phones, and it's been in the process of getting patched, but not all phones have been patched.
Whenever someone repeats this myth that NFC was hacked, I cringe. Miller didn't hack anything.
All he did was point out that you might be able to secretly pass a malicious website's URL via NFC to someone's phone without them noticing you did it. Yeah sure. Okay, let's say you did.
At that point, then the targeted user has to:
Not be surprised or suspicious about why their phone woke up and has a strange website showing.
Look at the website and click on a link.
Agree to the suspicious app download popup.
Go find the downloaded app.
Have app sideloading enabled.
Install the app.
Agree to all its permissions.
Oh wait. This lengthy scenario could happen with suspicious MMS and email, too. It really has little to do with NFC, and absolutely NOTHING to do with NFC payments.
Basically, he was just being a publicity hound.
That would certainly save the button having its own key but I was thinking of the scenario where someone steals your print data. If the phone sends the button the public key and they have the source data, they just take the public key, encrypt the source and send it back to unlock. If the button had the key embedded, a thief would have to physically hack every button for every phone to recreate the response but as I say, that makes it very problematic if the sensor is somehow replaced in the phone e.g by a broken home button.
It depends on what exploits/scenarios are being prevented. Obviously if someone gets an OS exploit, you pretty much have what you want anyway. But if there was a mass remote exploit that intercepted the sensor data from a lot of phones, it could be shared online and phone thieves could then run that database to unlock stolen phones.
I'm sure they've tested loads of methods to see what can be bypassed so it'll be sufficiently secure but it can't be impervious to some form of bypass. At the end of the day, every security system involves verifying a piece of data. This piece of data:
- has to be hard to get hold of by a 3rd party
- has to be convenient to get hold of by the user
- has to be unique so it can't be guessed or subjected to a mass exploit
It's very difficult to find a piece of data that satisfies all of those conditions because during any verification step, the user has to present the data. An exploit is easy once it's intercepted and if you can't change the piece of data, it makes future exploits easier.
The tech Apple bought (TruePrint) is supposed to scan under the skin to avoid that. It says it detects a pulse too so it would be harder to use a fake finger. There were tests done in 2005 that bypassed one implementation of it:
http://courses.ece.ubc.ca/412/previous_years/2005/modules/term_project/reports/2005/A_Security_Analysis_of_RF_Biometric_Fingerprint_Scanners.pdf
but they have probably updated the sensor since then to detect the pulse. Manufacturers who use these scanners might find a problem implementing them now that Apple owns the company making the technology.
Quote:
Originally Posted by Gazoobee
Well it wouldn't be a button if it was part of the screen. One of it's uses is that it allows blind people to use the phone. It has to be a physical button for that to work.
Um, no. I did not say make it part of the screen. I said make it as a screen like the glass trackpads. So you will have the dedicated button, but it will also act as a mini trackpad/bio reader.
Edited: I guess I see how this is confusing, sorry. So I suggest to make the home button a hybrid of a Home Button, Trackpad, and Biometric reader. This would add so much functionality to this button that awesome would not be a big enough word.
This could be used to scrolling web/email pages as well as, well, anything really. Use it for games as a joystick. Zoom in/out for maps or camera. Same as pinch, but you don't have touch the screen which at time is not as natural. Act out the camera in landscape and work the button to zoom in/out. Feel natural does it not?
I really think that could open up so many options and set the iPhone that much more apart from other phones.
If they were to put the sensors for finger print recognition in the home button then all of the possibilities you mentioned are opened up.
I would imagine that Apple could make an iPhone with a larger screen as well because then the whole 1 handed operation argument would be mute if most functions can be done via the home button.
After checking out the CardStar app, it appears to be everything passbook was advertised to be but isn't. Physical cards can be uploaded and digital cards can be added all from the app's rich database.
No downloading apps to add passes (which that process I've found to be hit or miss in passbook). And a large database of passes available for upload.
Apple should either learn from CardStar or buy them, but Apple's track record with updating native apps is pretty sketchy. I hope they fix passbook sooner than later but I have my doubts.
Then you have Google going for an entirely different way of working with passwords and websites
http://www.wired.com/wiredenterprise/2013/01/google-password/
They see a future where you authenticate one device — your smartphone or something like a YubiKey — and then use that almost like a car key, to fire up your web mail and online accounts.
In the future, they’d like things to get even easier, perhaps connecting to the computer via wireless technology.
“We’d like your smartphone or smartcard-embedded finger ring to authorize a new computer via a tap on the computer, even in situations in which your phone might be without cellular connectivity,” the Googlers write.
But for Google’s password-liberation plan to really take off, they’re going to need other websites to play ball. “Others have tried similar approaches but achieved little success in the consumer world,” they write. “Although we recognize that our initiative will likewise remain speculative until we’ve proven large scale acceptance, we’re eager to test it with other websites.”
So they’ve developed a (as yet unnamed) protocol for device-based authentication that they say is independent of Google, requires no special software to work — aside from a web browser that supports the login standard — and which prevents web sites from using this technology to track users.
This is really flawed because it makes 3rd party authentication dependent on the issuer:
http://www.linuxjournal.com/magazine/yubikey-one-time-password-authentication?page=0,0
Someone can hack or DDOS the core servers where everyone's private keys are stored. Google providing the service would be more reliable but I don't want to be blocked from accessing a service because someone else's authentication servers mess up or time out.
Requiring the user to keep special hardware is always going to be problematic and I don't think it's needed. Obviously it's used for payment systems (credit cards etc) but it's not convenient for regular services.
I think the best balance between security and convenience is to use challenge-response authentication and public key cryptography along with renewable and diverse private keys.
A practical example would be:
- sign up to a website and the server asks for a public key
- the device would generate a private key from fingerprint vectors and a random code and create a corresponding public key and sends the public key to the server
- the user device stores the random part of the private key behind a simple authentication
- when a server needs you to login, it just sends a random code encrypted using the public key
- your device decrypts this using both fingerprint and the random part of the private key and sends the decrypted code back for verification
If someone hacks the server, they'll only ever find the public key, which doesn't matter.
If someone challenges the server, they'll be sent an encrypted message, which they can't decode.
If someone intercepts the message, it's encrypted going down and just a random string going back. The connection would usually be over SSL anyway.
If someone spoofs a website, all they can do is send you a random code. They might be able to figure out the private key with a significant number of requests but the device would know to only submit a single response.
If someone steals your device, they have to bypass the local authentication, which can be behind a fingerprint id or passcode or both depending on circumstance. But they still only get half of the private key unless they recreate your finger touching the scanner.
These random parts of the private keys can be transparently or manually synced between devices with a fingerprint authentication and keys can be generated for devices without scanners.
It also means that if someone does recreate your finger authentication, they can't bypass all authentication systems because they still need the random parts of the private keys, which can be renewed and never leave a local device.
All Apple needs to do now is trademark 1-thumb purchasing before Amazon.
Quote:
Originally Posted by Curtis Hannah
Well sorta possible yet did you think it through that it still requires a digital button so home button forever.
The original physical button was necessary because iOS was new, and a simple wired interrupt button was easiest to implement.
Now, with a more robust OS and with the proper drivers, even an onscreen button should work fine. Or if they were still worried, they could even build the interrupt capability into the touchscreen (or touchpad area) controller itself.
Either way, the upshot is that Apple could use a capacitive Home button if they wished.
Side note: It should really be called the "Apps" button, since it goes to a list of apps instead of a traditional phone home page. That's also why Apple placed the image of a blank rounded app icon on it instead of a house.
Originally Posted by KDarling
Now, with a more robust OS and with the proper drivers, even an onscreen button should work fine. Or if they were still worried, they could even build the interrupt capability into the touchscreen (or touchpad area) controller itself.
Good luck with that: except it requires further sandboxing of apps, removing their top-level access to the touchscreen. I can imagine you'll have a few things to say about it when it (doesn't) happen…
Quote:
Originally Posted by Tallest Skil
Good luck with that: except it requires further sandboxing of apps, removing their top-level access to the touchscreen. I can imagine you'll have a few things to say about it when it (doesn't) happen…
Strange comments.
I'm neither pro nor con about it. I'm just responding to those who want to know if it's technically possible.
The fact is, from an engineering standpoint, there is nothing preventing Apple from using a touch home button if they wished.
Certainly there's no further sandboxing required. Apps don't have direct touchscreen controller access. Only the OS does.
Originally Posted by KDarling
Certainly there's no further sandboxing required. Apps don't have direct touchscreen controller access. Only the OS does.
And yet both lock up when one locks up. That's why something in the hierarchy has to change.
Quote:
Originally Posted by Tallest Skil
And yet both lock up when one locks up. That's why something in the hierarchy has to change.
You have a good point. That's why I suggested that adding interrupt code to the touchscreen controller (or its port) could be an end solution. That would make it outside of, and immune to, OS problems, just like a physical button.
Tech explanation: Apple uses a standalone touchscreen controller chip, which most likely communicates with the main CPU over an SPI (Serial Peripheral Interface) line. The CPU receiver should have an interrupt that can be fired when the controller sends touch data. Or, they could go further and have TI custom make the controller to have an independent interrupt output that could go to a higher priority CPU interrupt input when the user touches the Home area.
It doesn't matter whether an external interrupt comes from a button or a controller. To the CPU, it's the same thing.
Oops, forgot that readers might not know what an interrupt is. In this case, it's an external wire coming into the CPU that tells it to stop (interrupt) what it's doing and go execute a special section of code (called an interrupt handler). They're used for two main reasons:
2) Efficiency. Old or cheap computers must spend their time constantly polling for inputs. Keyboard scans, disk drive status, serial port in/output, touch, you name it... the CPU wastes its time checking to see if something is happening. Interrupts only happen when some data is ready, which means the CPU only has to handle the input when it's ready, and can spend most of its time doing things for the user instead... or sitting idle to save battery.
1) Robustness. Unless programmed code has turned off or masked an interrupt, the CPU must handle it. (And there's also usually one interrupt that you cannot turn off... that's the reset line.) That's the secret here: even if an app is out of control using up the CPU, firing the signal on the interrupt line will stop whatever that app is doing, and force the CPU to handle the interrupt. That's how they allow for the OS to take control back. (Most embedded computers like in your car have what's called a watchdog timer just for this purpose. No matter how the code fails, that timer is going to cause an interrupt and thus allow the CPU a chance to get back on track.)
Disclosure: I've been programming CPU interrupts since my first 6800 microprocessor kit in 1978. Back then, I had to compile assembly code to hex codes in my head and punch in those digits line by line. Oldtimers here will have "fond" remembrances of doing this.
Quote:
Originally Posted by Gazoobee
I hope this isn't true. It would make far more sense to integrate it into the screen.
Especially since they just spent millions buying a company with world-leading technology that does exactly that.
I can see a potential problem with this in that your screen is going to get covered in greasy fingerprints leading to more wiping and irritation. At least in normal touch-screen operation it tends to be the finger-tips used fleetingly rather than the flat of the finger used for longer.
For that reason it would be better to have the finger-print reader off screen.
Quote:
Originally Posted by Mobius
For that reason it would be better to have the finger-print reader off screen.
Plus, of course, the grease leaves your fingerprint on the screen itself, where a thief could lift it, assuming it was still there and okay.
(However, the better fingerprint recognition code of today also looks for a match to a previous login attempt. Rather than letting you in as you might think, it assumes that a _perfectly exact_ match to a previous login is likely to be a spoofing attempt using a fingerprint copy. The code would rather that each attempt be slightly different in alignment, viewable areas, etc, thus indicating a real finger.)
This is what we need for the gun industry.
Excuse me, was my post deleted?
Why shouldn't this technology be used for the gun industry? Put a thumbprint scanner on the gun so that only the registered owner can use it.
This is not a politically sensitive post, as I think both pro- and anti- gun rights advocates should agree that this is a good idea, no?
This post is related to the topic at hand, because we're talking about fingerprint scanning technology.
If some quick triggered (pun intended?) mod wants to delete this, then please have the courtesy to explain why.
Originally Posted by tonton
Why shouldn't this technology be used for the gun industry? Put a thumbprint scanner on the gun so that only the registered owner can use it.
This is not a politically sensitive post, as I think both pro- and anti- gun rights advocates should agree that this is a good idea, no?
This post is related to the topic at hand, because we're talking about fingerprint scanning technology.
If some quick triggered (pun intended?) mod wants to delete this, then please have the courtesy to explain why.
Please do start a thread on this! I think it's a fine idea. But you'll need to start it in PO.
I know why, you know why, your supporters know why, and your detractors know why. And it's not just because of topical events, but that is part of it.
Now, if you'd offered a use for fingerprint recognition elsewhere in the tech industry, absolutely it would have stood. But really.
Quote:
Originally Posted by Mobius
I can see a potential problem with this in that your screen is going to get covered in greasy fingerprints leading to more wiping and irritation. At least in normal touch-screen operation it tends to be the finger-tips used fleetingly rather than the flat of the finger used for longer.
For that reason it would be better to have the finger-print reader off screen.
And if analyst are right it would give another job to the already overworked home button, and keep Apple ahead of the competition. Somehow.