Ability to fake time

[hawaiikasper]

I think time is a privacy critical information as well, because some apps use it for collecting behavioral statistics.

The module "PerAppHacking" (https://github.com/t2k269/PerAppHacking) already makes use of this feature, there it's called TimeMachine.
It would be great to be able to set a static time, randomize on boot and randomize on access.

More info:
https://github.com/t2k269/PerAppHacking/blob/master/src/org/t2k269/perapphacking/HackService.java

if (prefs.getString(lpparam.packageName + "/timeMachine", "").length() > 0) {
     try {
     final long fakeTime = new SimpleDateFormat("yyyy-MM-dd HH:mm").parse(prefs.getString(lpparam.packageName + "/timeMachine", "")).getTime();
         final Long[] baseHolder = new Long[1];
         Class contextWrapperClass = XposedHelpers.findClass("java.lang.System", lpparam.classLoader);
         XposedHelpers.findAndHookMethod(contextWrapperClass, "currentTimeMillis", new XC_MethodHook() {
     @Override
         protected void afterHookedMethod(MethodHookParam param) throws Throwable {
     if (baseHolder[0] == null) {
     baseHolder[0] = (Long)param.getResult();
     return;
     }
     long baseTime = baseHolder[0];
     long currTime = (Long)param.getResult();
     param.setResult(currTime - baseTime + fakeTime);
         }
         });
         XposedHelpers.findAndHookMethod("android.text.format.Time", lpparam.classLoader, "setToNow", new XC_MethodHook() {
     @Override
         protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
     ((android.text.format.Time)param.thisObject).set(fakeTime);
     param.setResult(null);
         }
         });
     } catch (Exception ex) {
     // Ignore if the date is invalid
     }
     }

[M66B]

I don't see what this would add to all other restrictions. It should suffice to restrict personally identifiable information, do you think otherwise, and so yes, why?

[hawaiikasper]

What if you want to use an app where you are identifiable, because for instance you are using a license or an account that is related to your name?
I know the information would still be collectable by servers one is connected to but you can circumvent this by going in offline mode.

[banderos101]

Ive thought about this, and i know it might sound out there, but wouldnt knowing a devices timeZONE be a form of knowing ones location albeit very roughly, but still, its a potential location leak no?
Some apps might need this info, maybe could give them a seperate timzone, and those apps you need the correct time and relatively trust, you could unrestrict.

I dont know how dependant all apps are on having the "time", maybe many dont need nor call, but it would be nice to have this angle covered none the less

well thats just my thoughts on the matter

[Cerberus-tm]

I think Hawaii Kasper has a good point: if you need for an application to know your identity, and the application doesn't have to connect to the Internet all the time, the time data could give it lots of behavioural information. Perhaps this should not be top priority, but it would be useful for our privacy if we could some day spoof time.

[jpeg729]

There are different sorts of time
getSystemTimeMillis reports the number of milliseconds since the device has booted and is often used for delays, animations and so on. Things would get really weird if we restricted that.

On the other hand being able to set a time zone and have the other time functions adjust time accordingly would be much more doable.

[jpeg729]

Maybe all we need to do is to call TimeZone.setTimeZone( defaced timezone ) early in the apps startup
http://developer.android.com/reference/java/util/TimeZone.html#setDefault(java.util.TimeZone)

On the other hand, this is something that will have a direct effect on the users experience. Much less than changing the locale and thus the translation used in apps.

XPrivacy currently doesn't have any notion of optional restrictions - for things like the locale or the timezone that vaguely help identify the user, but that most people will prefer not to use because of the effect on the user experience. So I vote against.

[Cerberus-tm]

@jpeg729 So what potentially negative effects do you foresee for spoofing time? If an application thinks it's 13.34 instead of 6.02, what would happen?

[jpeg729]

It is the user experience I'm worried about, because restriction will be enabled by default, users would have to turn it off for apps that display time annoyingly incorrectly. Of which to be honest there aren't that many. I'll change my vote.

[hawaiikasper]

How about this option will be first marked red (is dangerous, restricting may cause problems)? So it won't be enabled by default.

On February 17, 2014 4:39:15 AM CET, jpeg729 [email protected] wrote:

It is the user experience I'm worried about, because restriction will
be enabled by default, users would have to turn it off for apps that
display time annoyingly incorrectly. Of which to be honest there aren't
that many. I'll change my vote.

---

Reply to this email directly or view it on GitHub:
#1362 (comment)

[M66B]

Adding this feature is simple, but the problem I have with this feature, is that it can be misused and that privacy is just served a little.

[banderos101]

i know what you mean, but if everyone starts taking that stance, an understandable stance, then inevitably, folks will figure out that is is a consistant way to, for whatever reason, find a rough estimation of location
If you do end up adding it, maybe dont particularly advertise the feafure, beyond the changelog...if you do end up adding it

This probably is a bigger debate, but personally, i dont relish the idea that users might not get certain restrictions that would protect their privacy, because of those that might misuse it.....
I, know, you implemented it for privacy, others, know you implemented for privacy, anyone who says or implies otherwise, is not someone i'd take seriously on the subject, as what their knowingly or unknowingly calling for is LESS protection, and i cant stand behind that, even knowing there might be users misusing it, but thats just my personal view on it, not just limited to the scope of xprivacy.......whatever you decide though, its upto you, but my vote says to add it, and if you feel you need to remove it later, fair enough, this is your baby

[M66B]

The reasoning is not that I don't want to add it just because it can be used in a malicious way, but that the minimal added privacy does not outweights that problem.

[jpeg729]

If an app doesn't use internet, the importance of restricting is mitigated,
and if an app does use internet then the device's external ip address or
that of the router, is a good source of rough location info. When on a data
connection this can be really inaccurate - I've seen ~200kms, it is
probably far more accurate on a wifi connection on ISP's that give
unchanging ip addresses. Ever wondered how google know roughly where you
are when you are using a pc without gps?

The only way to get round that is to use a vpn and I doubt many users will
take that step largely negating any benefit for 90% of users.

[Cerberus-tm]

@jpeg729 I thought the way Google knew your location based on Wifi was because they have a database connecting each Wifi access point with GPS data directly (collected automatically all the time on millions of devices and possibly Street View cars in order to populate the database), not because they link you to your IP address? Mozilla's new alternative location service will work the same way; you can help them collect data by downloading Moz Stumbler on your phone and setting it to "scan" once in a while.

"If an app doesn't use internet, the importance of restricting is mitigated,"
— The most common scenario where this would be useful is for an application that occasionally connects to the Internet, but not all the time. This could be, for example, only when I'm on on Wifi. A theoretical example would be Swype. If it stores the time stamp when I type certain words 24/7, and sends this time to its servers once a day via Wifi, it will give them a lot of data about me.
I happen to be thankful enough to Swype to give them those data, but we can't be sure they properly anonymise them, so I can understand why some users might not want to let this happen, while they do want to receive Swype's dictionary updates once in a while.

@M66B Our of curiosity, how could spoofing the time be "misused"?

[jpeg729]

That is the usual way, but not the only way. See this page
http://www.ipligence.com/geolocation for me it is accurate to 1-2km on my
home internet connection.

[Cerberus-tm]

@jpeg729 I know this is possible, but I did not think Google was using this method in Android. The reason I assumed to be threefold:

• It only works when you are connected to Wifi Internet, which is often not when you need your approximate location;
• You will probably have a somewhat more accurate location already through cell towers at the same time (your link is about 3 km from me, whereas cell towers get within 750 m);
• Wifi-GPS coupling the way Google does it already provides a far more accurate location anyway when you're near a Wifi acces point, so there is no real point in additionally getting your IP address (except if Google is trying to circumvent Xprivacy...).

Either way, I don't think spoofing time should be high priority: I'm just defending the merits of the idea in general.

[jpeg729]

As far as I know google don't, but an app that connects to a dedicated server could easily do that.

[M66B]

I am not convinced that the advantages outweighs the disadvantages, so I am closing this request.

[Cerberus-tm]

I agree that this would be of lesser usefulness. And I can understand if this is not worth the effort. But, by "disadvantages", do you mean the effort it would take to create this category, or something else?