Hacker News Reader

Comment by daghamm | Hacker News Reader

Looks like they have added tons of features for this. This one really caught my eyes.

"Theft Detection Lock is a powerful new feature that uses Google AI to sense if someone snatches your phone from your hand and tries to run, bike or drive away"

View on HN

It sounds like a nice feature but in my experience such "auto-magic", always-on features can burn battery life. It's not necessarily much for each single feature but there are so many of them these days, they add up quickly.

The other downside is false positives or other occasional failure modes. Many such "auto-magic" features choose not to expose any granularity to the user, perhaps because they think it'll make it less "magic" or that a few entirely optional scaling settings in an "advanced" tab will hopelessly confuse users. Too often such "all or nothing" reliance on the infallibility of their magic 'do-the-right-thing' code forces me to entirely turn off what would otherwise have been a useful feature.

Fortunately the accelerometer is a very low-power service. There shouldn't be much magic required, simply a threshold for accelerometer activation similar to drop detection. This sort of protection can false-positive fairly safely - it is minimal extra burden to unlock your device if you accidentally drop it, for example.

Yeah, I've learned the smarter they try to make my device, car, etc. the more annoying it becomes in practice because of all the edge cases I seem to bump up against regularly.

Yeah, there's a growing cult-ish obsession in UX design that sees all customization, optionality and user choice as some kind of flaw in their perfect minimalist designs. Frankly, it's kind of bizarre. Our tech is powerful enough and our platforms flexible enough that every user should be able to "have it your way" (as Burger King liked to say).

What you're describing is the UI/UX design paradigm of prosumer tools like blender. Unfortunately, despite how important this class of software is, SV seems to have institutional blindness to how and why this kind of software is even built.

For example, we have the greatest opportunity in a generation for someone to build "photoshop for text" i.e. a proper GenAI based LLM tool with similar design choices. LMstudio is the only even close example of this, and they're not getting it in the way that blender does.

You dont notice them when they work as intended, but when something odd or annoying happens it leads quickly to disappointment.

For me its car's lane assistant, interfering with driving is big no for me. Asked my father to turn it off on their new mazda 3 too, 99% ok behavior is simply too low, even 99.9% would be.

Oh yes. This is a huge one for me. My wife bought a luxury car that's loaded with these new driving "assist" features and they're both annoying and extremely distracting to the driver. Worse, when they unexpectedly grab the wheel while I'm actively trying to steer, it's caused me to swerve while fighting to correct it. Fortunately no road incidents yet but these are clear safety issues. If it were a commercial aircraft instead of a car, pilots would be required to report them as incidents.

Of course, I always turn these stupid features off but, inexplicably, my wife likes them and keeps turning them back on. So when I happen to drive that car it continues to be a nasty surprise until I remember to turn it off. This also makes a separate UX failure even worse. Settings like seat position, enter/exit behavior, navigation and even entertainment options are stored and recalled in per-driver settings. These per driver settings can also be linked to each key fob. She has her fob and I have mine. Very nice - except these damn driver "assist" features are NOT stored in per-driver settings like they obviously should be!

Damn it, car UX designers - all user options should be stored per driver. It's a few KB for bit flags and single-byte values, it's not like we don't have the storage these days.

Lane assistance is fine, if it can be permanently disabled. But I've rented cars where it seemed to have been hard coded to default = ON for each trip. Every time I started the car, I had to go into the car config (great fun on a rental with a different GUI each time) and disable it before driving.

Otherwise, in city driving, it's like some paranoid front seat passenger grabs the wheel every 30 seconds.

Its a lawsuit waiting to happen. Yes it can be disabled on normal cars, but on rentals not consistently, they do sometimes lock down settings menus - driving with it around narrow Sicily roads was not pleasant at all, outright dangerous in few situations.

I've never noticed this at all. The only smart features that ever really give me trouble are gestures and shortcuts.

You don't need Big Brother Google accessing your sensor data, nor do you need AI for this. I've been using this app for years and it works great in locking the device if someone grabs my device. https://f-droid.org/en/packages/com.wesaphzt.privatelock/

Sounds potentially useful, but question...

If you're trying to call 911, or you're trying to video an assault... and someone tries to stop you, such as by jostling you or your phone... what's the likelihood that this Private Lock will get in the way of that?

I believe Android has an SOS feature where if you click the power button five times in quick succession, it can take a photo and send a very scary-looking SMS message to a relative or some other trusted contact. I don't know if it lets you set it to call 911 or take a video though.

You can do both of those things from the lockscreen of any android device I've used in the last decade. The linked app just seems to engage the normal android lockscreen.

Is it really "Big Brother" when the model runs locally on your device and doesn't send any personal info to anybody?

Ideally no, not "Big Brother". But this is Google, and the burden of proof is on them to not collect data "to make our services better", etc.

Especially location data. If something like Find My Phone is activated, my immediate bias is to assume Google is taking advantage of this data collection to monitize my data without my consent.

It's not clear that any sensor data needs to be sent to Google for thois to work. I suspect this is all on device.

You're saying it works great, which makes me wonder how often your phone has been snatched away?

Google already has this data, because every app has access to sensors by default and GMS has always on location access anyway.

Even on graphene OS, location without GMS is almost unusable.

I expect it can work more efficiently as part of the OS rather than as an app.

That caught my eye too. For whatever reason I thought of how Ross Ulbricht, Silk Road founder, was arrested when FBI agents used a ruse to snatch his laptop from him before he could lock the screen.

I keep thinking about how that scene played out. Where would Ross be had he had the time to shut the lid.

Nearly all phones mounted on drones would trigger that "feature".

Like dropping the phone just as you’re about to start cycling.

I don't understand the point of features like this. OK awesome that thief can't use it, but I've still lost my phone. It hasn't prevented any loss.

The idea is that with features like this widespread, the probability of a theft leading to the thief repurposing the stolen device will be lower. Therefore, the incentives for thieves – the ones acting rationally within the paradigm of being a thief, at least – will be lower. Therefore, the number of thefts, generally, may go down. A few big ifs here, of course.

I've always felt that system lock was about preventing theft of the device data, not prevention of flipping the device itself. Like tons of other people, I have sensitive apps and data on my phone (banking, cloud services, etc), but unlike tons of people, I take great care to ensure logouts after I am done accessing said apps or data. Even so, a thief snatches my phone, I don't care what happens to the phone itself, so long as the data is safe.

Knowing the thief does not have access to my email, banking apps, nudes, etc is worth a huge piece of mind.

The phone is worth less to the thief, so theft becomes less lucrative and there is less incentive for the thief to steal your phone.

The cost of your phone might be low or covered by insurance, while all your private information is much more valuable.

I never spend more than 200 euros on a phone and consider them disposable. If I lost my (locked) phone, I'd merely get my (identical) backup phone from home and continue as if nothing happened.

The world runs on incentives. Remove the incentives you remove most of the behaviors.

A rare case of actually useful AI features. Thumbs up!

Is it AI or just ... recognizing a pattern?

How much data could it have to look at in the time that someone "snatches" a phone?

The article continues with:

> If a common motion associated with theft is detected, your phone screen quickly locks – which helps keep thieves from easily accessing your data.

So it's probably a machine learning model that was trained on motion data of snatches, but it's likely not AI in the sense of LLMs.

But I wonder how many false positives this could yield. For example you are in a hurry and you snatch your phone from a table. How precicesly can this model decide with just motion data, if this was theft or not.

Personally, I would take the false positives. Way too much of my life is locked into securing this fragile black rectangle. Unlocked phone has access to basically everything. I personally do not do any finances on my phone, but all of the MFA works through it.

If I snatch a phone from the table (probably already locked?) or drop it, I will suck up the additional login.

I have long thought about the utility of a little locking-beacon. If phone suddenly gets out of range, should auto lock. If only Bluetooth were not so unreliable.

Worth noting Android (or at least Pixel) does have a feature like this, but it actually does the opposite: while a Bluetooth device is connected it keeps the phone unlocked. It would be way more useful in the reverse: that if a Bluetooth device disconnects, it should lock.

These are two different things, since I do not want my phone to have no lock screen just because my headphones are sitting near it, but if it is unlocked and suddenly my headphones disappear, that would be a useful precaution, even if it doesn't eliminate the risk on its own.

It's called Android Smart Lock and has been a thing since Android 5 (Lollipop). It also works (worked? Does it still exist) with 'trusted places' (GPS/WiFi), Voice/Face (before face id was a thing) and a mode were it kept the phone unlocked as long as you kept it on your body.

I remember that I used the last option many years ago, as that was really convenient and worked very well. Basically as long as the phone was in your hand or pocket it kept unlocked, but as soon as you laid it on a table it got locked.

But now that fingerprint unlock is a thing, I don't even mind unlocking my phone as it is one fluid motion and happens unconsciously.

You can do something like this with an automation in the Shortcuts app on iOS.

My Apple phone won’t let me do some sensitive things if I am in an unusual location. It’s a default setting.

If my phone gets nabbed, a motivated thief would do nefarious actions the minute they get out of site. So presumably just a few blocks away from a usual location.

It's a classifier, like ML has done for many years.

There's a saying that when something becomes mainstream it is no longer considered AI. Fun to see that being reversed.

How on earth do you even get training data for this? Recorded phone sensor outputs that are known for certain to be the result of validated, confirmed theft events can't possibly be that common. Are they paying people in Bangledesh a few bucks to be randomly assigned to group that either get robbed or tripped in the hope they throw the phone and labeling sensor data accordingly. When this type of motion recognition was first developed, they had labs and recorded people walking, doing jumping jacks, sitting and then standing, whatever, and labeled the patterns appropriately because they knew what was happening because it was happening in a lab.

I'm trying to decide if parents with small children will either love or hate this feature.

Google is really going to crush those little toddlers dreams of finally getting their hands on the phone :(

Would be interesting to know the difference between a snatch and me rushing out the door...

Probably the acceleration vector. If the phone is rapidly moved a meter away from you, either it's being snatched or it's being thrown.

Edit: To clarify, I was thinking of horizontally, in the direction that corresponds to the top of the screen, as if you were bent over using the phone--probably holding the bottom-of-screen--and then someone grabbed the top-of-screen to pull it away.

> If the phone is rapidly moved a meter away from you, either it's being snatched or it's being thrown.

Good heuristics. Also that must not be a mainly downward rapid movement, which probably only means you just dropped your phone.

A drop registers as no acceleration while in freefall, and then a sharp spike when it hits the ground. This was counter-intuitive to me when I first figured out how to display my phone's accelerometer readouts, but makes sense.

I think a lot of the false-positive cases where the screen gets locked are acceptable in context.

I mean, most people dropping their phone will be too glad/devastated that the device did/didn't escape harm to bother being annoyed that they have to unlock the screen again.

Do you often interact with your phone via the screen while rushing out the door?

Yes. Often the map or messaging app.

Yes?

I would expect this to not make a difference if your phone was already locked. But I guess Google could only lock the device if it was upright before being grabbed.

I mean, worse case scenario, your phone just locks (I assume to the lockscreen, where you have to re-enter your pin). It doesn't seem like such a big problem?

There are free and open source apps for Android that automatically lock the device when the accelerometer detects rapid acceleration, which is a simple detection method. For example, Private Lock is on F-Droid:

- Private Lock (source): https://github.com/wesaphzt/privatelock

- Private Lock (F-Droid): https://f-droid.org/en/packages/com.wesaphzt.privatelock/

Very interesting.

Gotta admit first thing I would do is stage a theft scenario to see how it works.

Linear regressions are machine learning.

AFAICT all machine learning models right now are just pattern matching.

AI is another word for training-based computerized pattern recognition.

:) So one way I immagine it does this is by listening in on your microphone to determine a distress signal. Up to you if you think this is cool. In general people should ask themselves do they really want a semi-intelligent program someone else trained "living" in their phone. Yikes. I tried to uninstall the neural network package on my Android but it is impossible since it is an actual system package. Why on earth it should be an Android system package is beyond me. Moreover this issue persists even if you use a de-Googled privacy and security focused distribution like GrapheneOS

Yes but that's only in your imagination, it's not how the feature works. The feature works based on motion detection trained on specific "theft patterns".

Because you trust how it is marketed. The android neural network package is system deep, meaning it could easily bypass all software permissions for hardware

Reply on news.ycombinator.com