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...
At my last job the HR guy installed this super annoying Slack bot that would spam everyone every week with a "happiness survey". I got so tired of it I eventually logged the requests my survey made and used curl to replay one with a happiness score of -100 (usually the value would be between 0 and 10). Response said "success".
Turned out the backend happily took that value and it skewed our average a lot and the next week I was laughing my ass off while HR was trying to figure out why everyone was suddenly so unhappy.
My favourite too was being new into a development job and buying our biggest package for a penny. What I hadn't counted on was that this was a fairly new system and the CEO was still copied in to every buy order.
Thankfully the company took it in good spirit, I was even sent an expenses form to reclaim the penny! :)
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).
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.
But aren't iOS users most likely to spend money? Thus making them the perfect users to target if you're eventually going to show ads, or rent their information, or monetize in any way?
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.
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...