Prevent timestamp manipulation?

[Dialect_Junk]

Is there a way to ensure that the timestamp is the actual time and not the device’s time?

We just discovered someone manipulating their timecard by manually setting the device time and then punching in to show they were on time. Sneaky…

I can go into the audit logs which timestamps the actual time of the operation to verify but this would get pretty cumbersome when trying to manage 35+ timecards.

The device’s belong to the employees and we install the app on their phone.

Thank you.

[1minManager]

@Praveen sorry to add even more to your workload. But if you are looking at the timestamp to make it more secure, can you do the same with the GPS location? One issue we noticed about 12months ago was that if you are on wireless, sometimes Appsheet uses the internet connection location, presumably via the DNS record. Is there any change you can force Appsheet to only use the GPS receiver?

How we worked this out was with the above company sometimes they couldn’t clock in. I went to site and ran some tests. Google Maps was reporting my location correctly but Appsheet was getting a location about a mile away. When I turned off wireless on my phone and Appsheet then got the correct location.

Simon@1minManager.com

[MultiTech]

@1minManager you’ve seen this right?

[1minManager]

@MultiTech_Visions yes. But its not clear how it works. We can have 40-50 people doing multiple time entries per day, and each one has a Change_Location on both the start time and end time. So the limit of 1000 is potentially not enough. Also its not clear why this limitation is in place if its just pulling a Lat Long from the GPS receiver.

[Rafael_ANEIC-PY]

This was a wild but very informative read, so much experience shared ! im grateful.

Any updates on the “tamper-proof” solution? @praveen

[Wesley]

I’m trying!

Preventing Timecard Manipulation with Hardware Battery Time since Power Cycle Questions

In the way AppSheet can see a unique device identifier can it receive the device hardware battery time since power cycle? I don’t understand the specifics but the key is the battery time since power cycle being un-changeable in a way system time isn’t, and comparing battery run time before/after successful syncs and when the record is saved. I don’t need this but it seems it may help - key would be the employee in field with no service couldn’t let their phone die between syncs.

[Luis_Reyes]

Tengo el mismo problema se me ocurre que AppSheet defina una función fingerprint() para que cuando el trabajador llegue a la empresa su hora de entrada se registre al momento de leer su huela dactilar en la aplicación de AppSheet.

Claro esta que para hacer esto, debería estar una Tablet o dispositivo móvil fijo en la empresa o sucursales de la empresa., y de esta forma se obligaría al trabajador a llegar temprano sin necesidad de usar también el GPS (LatLong).

[HenriqueAguiar]

I'm also having the same problem mentioned above. Our solution is to use the audit history log analyzer (in our case weekly) to compare the timestamps on the sheets with the one said on the audit log. We found that some users were tampering with their device's phone and sent an e-mail warning about the tampering. Haven't happened since, but it's a really time-consuming task to every week/month do an audit on all of our worker's sheets. 

Would love if there was an anti-fraud method, one which we could trust it would say the correct time on the sheets even if the user try to fraud it.

Great read on some of the solutions so far.

[scott192]

Without providing any script to do so...would an Appscript Task to query the current time and store it in another field with the value of NOW() from the App itself be able to resolve this?  This is of course if you are using Google Workspace account...?

[dbaum]

Indeed, you could presumably define an automation event that triggers every time a new record is created with the timestamp you want to validate. That automation could log its own timestamp via a Call a script task (or perhaps other types of tasks defined to reference the server's time). The timestamp captured by the automation could overwrite, override, or just be compared to the timestamp from the device. Keep in mind that the automation would only trigger when the client app syncs data to the server; if you're dealing with extended offline usage, the locally captured timestamp and the timestamp from the server will (appropriately) differ.

You don't need a Workspace account to run an Apps Script project.

[SkrOYC]

You could make an bot to set the server's timestamp when there is an add as well as a timestamp from row creation (on the device) and compare both if you need.

As explained before, this is a little cumbersome because people can use apps offline but I'd say that the offline usage has some obvious cavieats that we should learn to accept to this point

[comgen_technolo]

sorry to bother you, can you help in creating a bot for server's timestamp? 

I have made a sheets script to get date when  unique id is added to the column, its working when i add unique id on sheets but when i create new record on app, its not working. 

function onEdit(e){

const sheetName = "Sheet 1";
const currentDate = new Date();
const row = e.range.getRow();
const col = e.range.getColumn();

if (col === 1 && row > 1 && e.source.getActiveSheet().getName() === sheetName){


(e.source.getActiveSheet().getRange(row,2).getValue() == "")
{e.source.getActiveSheet().getRange(row,2).setValue(currentDate);

}

}

}

[SkrOYC]

Just use an action to "set the value of some columns on this row" as a task on Adds only

[comgen_technolo]

That helps for now. Thank you very much.

[Ramitch_Palmare]

Do you guys think calling a script to make a timestamp in google sheets (apart from timestamp in appsheet which can be overridden/manipulated) can help this issue?

[SkrOYC]

It's not better than using a bot for it, unless I'm missing something