HN user

benhirashima

53 karma

Co-founder of RealityCap http://realitycap.com

Posts5
Comments18
View on HN
Project Tango 12 years ago

It's great to see mobile 3D scanning receive validation from a major player like Google. My company, RealityCap, is working on bringing 3D scanning to mobile devices without the need for specialized 3D cameras. We use the sensors already present in smartphones: the camera (monocular), accelerometer, and gyroscope. That means that we can bring 3D scanning to millions of mobile devices that already exist. http://realitycap.com

i think it's ridiculous that in order to get a prescription for a simple low-risk medication, i have to call my doctor, make an appointment, wait 45 minutes past when my appointment was supposed to be, and have a physical meeting with the doctor that consists of nothing but talking and takes all of 5 minutes. oh, and i have to pay way too much for it too. i should be able to do this over the phone or internet, and for less money.

thanks for the link. it was a good read. however, i see nothing in there that suggests that using a pepper is necessarily a bad thing.

i think the answer from rory mcclune puts it well: "Another add-on I've seen to this is to also add in what was called a pepper value. This was just another random string but was the same for all users and stored with the application code as opposed to in the database. the theory here is that in some circumstances the database may be compromised but the application code is not, and in those cases this could improve the security. It does, however, introduce problems if there are multiple applications using the same password database."

one strategy that has occurred to me is to use a secret "master" salt, in addition to random public salts for each password. that way, an attacker would have to obtain the secret salt, as well as the public salts. the secret salt would be stored in the program that does the hashing, and not in the database. this requires an attacker to gain access to the filesystem where the program lives, as well as the database. of course, this offers no guarantees, but does make it harder for the attacker.

from wikipedia: "A public salt makes it more time-consuming to crack a list of passwords. However, it does not make dictionary attacks harder when cracking a single password. The attacker has access to both the encrypted password and the salt, so when running the dictionary attack, the attacker can simply use the known salt when attempting to crack the password."

agreed. web developers have been dealing with different sized monitors for years. yes, it's a pain, but they manage. mobile is no different. coming from a web dev background, it was natural for me to consider varying screen sizes, but i guess some mobile devs haven't quite gotten the hang of it yet.

IMO, this article leaves out the most important aspect of android fragmentation - manufacturer customizations. HTC's Sense and Motorola's Blur are the top two sources of headaches for my app, Unlock With WiFi. manufacturers like to change the way lockscreens work, and in the process they introduce bugs that i have to work around. for me, android fragmentation wouldn't be half as bad if all phones ran vanilla android.