Not trusting user input is a good start, but the client shouldn't be trusted, either.
I have seen plenty of web apps that fell short on this...
Whenever I'm on a web app that has a button shown but disabled, you can be pretty sure that I will enable that button and click it...
If the client is limiting the maximum length of the contents of a textbox, I'm probably going to change that and see if the server is performing the same validation...
My favorite so far, though, was client-side calculation and validation of order amounts for some products. Intercepting the JavaScript file and tweaking it before the browser started using it allowed me to place an older for a bunch of products for only $0.01 (going negative was also attempted, too, but this particular system did a pre-approval with a payment gateway and it didn't like that... so I settled on a penny).
These were all things I've done with permission, of course... but it's amazing what you can do when people assume the browser will always follow the rules...
Dwelling in the past is a waste of time, but so is living in the future... Focus on what you can do now. Today. Otherwise, it becomes too easy to put things off for Future You to deal with...
I liked the part about it being encrypted and secure. Uh-huh. At least until one of these employees picks up something with an embedded RFID cloner... Even if the underlying data in encrypted and considered unusable by the 'bad guy', they can still use it in the encrypted form to impersonate the employee... sooooo....
¯\_(ツ)_/¯
Implants are great for both the novelty and the convenience, but I don't like it being pitched as somehow being inherently more secure than a standard access card or whatever (beyond it being more difficult to have your hand stolen or misplaced).
Yep. iOS users tend to spend more, in general. Think of this in the context of the specific application, though.
This is a proximity-based messaging. Without people nearby with the app, you have no one to talk to. At that point, ads or renting of information are meaningless... because it won't be used.
For a proximity-based application like this, purposely excluding the majority of smartphone users seems like it will be a limiting factor in its adoption.
But, who knows, maybe this is all intentional. I'll optimistically assume they are beta testing with iOS users until the kinks at worked out and can release to Android.
Last time I checked, iOS has about 14% market share, while Android has 79%... Especially for something meant to be by proximity only, you'd want the highest chance of it being on the phones of people nearby... heh. Instead, this gets released on iOS only. Good luck with that.
I have seen plenty of web apps that fell short on this...
Whenever I'm on a web app that has a button shown but disabled, you can be pretty sure that I will enable that button and click it...
If the client is limiting the maximum length of the contents of a textbox, I'm probably going to change that and see if the server is performing the same validation...
My favorite so far, though, was client-side calculation and validation of order amounts for some products. Intercepting the JavaScript file and tweaking it before the browser started using it allowed me to place an older for a bunch of products for only $0.01 (going negative was also attempted, too, but this particular system did a pre-approval with a payment gateway and it didn't like that... so I settled on a penny).
These were all things I've done with permission, of course... but it's amazing what you can do when people assume the browser will always follow the rules...