frizensami

Joined 6 years ago

Karma
434
Submissions
56
Member since
Nov 19
Interested in the intersection of sensing security research, education, and effective social impact.

Graduate Tutor and PhD student in the Sensing, Embedded, and Network Security Group at the National University of Singapore.

My personal website: https://sriramsami.com

View on Hacker News

Recent submissions

Comment · 5 years ago
Ah, I see. Thank you!
Comment · 5 years ago
Yes, I agree. I believe military-grade optics detection systems use multiple wavelengths, and some even use short bursts of visible light, making it harder to block.
Comment · 5 years ago
Interesting question. Mainly as mentioned above we needed Google Play Services for AR. Nothing else stands out at a high level.

However there is a clear bottleneck with the Google AR team for features that the community really wants. While it's understandable, perhaps the open source libraries aren't the priority or there's short staffing, there are issues like this one - https://github.com/google-ar/arcore-android-sdk/issues/153 - that have been open since Jan 2018. This one asks that we can use the smartphone flashlight simultaneously with ARCore, but there's no visibility on how close we are at the moment. This feature would have likely improved our work's performance greatly, but even in general, many other AR developers are asking for it.

Re: overcoming it, there's not much we can do in this case. We just didn't implement the feature.

Comment · 5 years ago
Oh, I must have misunderstand, since the root comment was talking about detection methods. But yes, jamming is a good option, and there have been papers to make areas "unrecordable". I don't have my citation manager on hand now, but I think it was an early ACM Sensys / Mobisys research work.
Comment · 5 years ago
I'm not sure that it's a conclusive yes here. We have a procedure to remove the effects of background reflection saturation by constantly analysing the maximum reflection size. So if there's a large reflection in the scene, we walk the user back til we have all reflections at the same size or smaller than the the larger expected hidden camera reflection. This works fairly well.

However, if the camera reflection is always within a larger reflection for all possible distances and angles, then I doubt this will work.

Comment · 5 years ago
Funnily enough this is exactly how we started the project, just with a different Thinkpad model.

Separately, Lubos, the creator of ToF Viewer, is very helpful to the ToF community and constantly answers any questions about APIs or sample code. I'd recommend talking to him if anyone wants to get started with ToF-based applications.

Comment · 5 years ago
Comment · 5 years ago
Agreed. I expect however that any easily available thermal sensing, especially on smartphones (see FLIR, etc), could be easily defeated with a strong adversary doing good thermal management.

As you say though, extra heat is a physical guarantee, so maybe a smarter technique exists to separate signal from noise in the thermal domain that I don't know of yet.

Comment · 5 years ago
There's a lot of marketing involved in this naming, with Samsung calling it DepthVision and Apple calling it LIDAR. There may be a difference here, however. My understanding is that Apple LIDAR is doing what we call "direct" ToF, where the round trip travel time of laser pulses is actually measured (this can be in nanoseconds). This lines up with what self driving car (and other expensive) LIDARs do.

Most other ToF sensors use "indirect" ToF, where they measure the phase difference between incoming and outgoing signals to derive distance.

However, it gets murky as cheap 2D LIDARs on say, robot vacuum cleaners, use geometric techniques to find distance (basically return angle of a reflection). I explored this in a previous work.

TLDR: I would recommend not taking any naming at face value and reading the actual datasheet or more commonly, technical marketing materials, since few ToF manufacturers that I see have a public datasheet.

Comment · 5 years ago
I don't think so. There's "laser-assisted autofocus" which might be slang for an actual ToF sensor, but sometimes that's just a single laser pulse (I.e., no 2D image that we need).
Comment · 5 years ago
Agreed, and a very valid point that these off the shelf detectors are pretty cheap compared to ToF smartphones. There are a number of unfavourable things about the detectors though:

- No automated detection, so lots of human subjectiveness on whether a bright spot should be investigated

- Background lighting can be an issue, so the view through the detector can be filled with bright reflections

- When I tried this for longer than 30 seconds, there's really some eye strain involved

The idea is that the smartphone has more than this one purpose, and the detection system can improve with software updates, whereas you get what you see with the detector and nothing more.

Comment · 5 years ago
It could also possibly work on iOS, but there's a catch we have not yet explored. We're relying on something called the "confidence" score in the ToF camera API, which has 8 possible values (3 bits) in Android, but from what I last saw, has only 3 possible values total in iOS. It's not clear how this lack of info exposed by the APi will affect accuracy.

This is something we'd have to separately test, and ultimately make a wholly different app for if it's feasible on iOS.

Comment · 5 years ago
I don't think this works, mainly because an extremely bright external source of 850 nm light looks incredibly suspicious through the sensor (as we expect the ToF sensor to be the only light source). We could add that check in explicitly.
Comment · 5 years ago
Thank you! Hoping for higher resolutions soon.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton