Add whitelist option to allow all ports of a url

[an0n981]

My reason for asking for this the following:

The app Redphone (org.thoughtcrime.redphone) always connects to SomeSubdomain.whispersystems.org:xxxx when it connects an encrypted call. The problem is that it always connects to a different dynamic port. Each time an incoming or outgoing call is connected, a onDemand popup with the option to whitelist either SomeSubdomain.whispersystems.org:xxxx or * .whispersystems.org:xxxx or allow all connections (which is suboptimal for an app like this)
The idea would to add an option to allow * .whispersystems.org: * (either in the onDemand popup or maybe in the whitelist manager)

I assume there are also other apps that would benefit from this.

[danielmmmm]

1+

[hollal]

+1

[wbedard]

+1

[SWADED]

-1

[vibes340]

+1

[banderos101]

+1

[Magissia]

Plus one. But should be a check option and no other way.

[pylerSM]

+1

[Dreamdance61]

+1

[baleu]

+1

[M66B]

+1
http://forum.xda-developers.com/showpost.php?p=52767556&postcount=9333

[M66B]

A note about this request: since there needs to be done an extra check, there will be a performance impact.

[M66B]

Test version: http://www.xprivacy.eu/XPrivacy_2.0.24-2.apk
Please report if the port wildcard works for both IP-address and domain names.
Also please report if there is a difference in performance.

[an0n981]

As far as performance goes, I can't notice a difference, but my device is really fast.
Wildcards for IPs/domains has a bug:
If I allow (insert xprivacy ip here):443 or you.know.urIP. * :443 for the xprivacy app everything is good, but if I allow some.IP.address. * : * it unrestricts the connect method. The same goes for apps that use dns names

[Magissia]

Really great we get this feature, thanks you M66B, considering donating again, you're awesome <3

[M66B]

@an0n981 I don't see anything obvious wrong in the code. Basically there is no difference in handling the different types of white/blacklist entries. However, I can imaging conflicting white/blacklist entries for the same restriction. In this case XPrivacy will pick the first one (in the same order as you see them in the on demand restricting dialog). Could you please take a look which white/blacklist entries you have for this application/restriction?

[M66B]

I like to see reports about performance for lower end devices too.

[an0n981]

In order to test this I first cleared the whitelist, otherwise I would not have received the popup for the XPrivacy app while submitting since it only has one entry (two if you never removed the old server IP from the whitelist). Another good example is Orbot (org.torproject.android) which only has one DNS entry (localhost:9051) Please try to submit restrictions once after clearing the whitelist for XPrivacy/IP

[an0n981]

Also worth mentioning is the fact that in addition to unrestricting the connect method is that no whitelist entry is even created when selecting x.x.x. * : *

[M66B]

Another test version: http://www.xprivacy.eu/XPrivacy_2.0.24-3.apk

This version should fix the bug reported by @an0n981 and fixes the defaults for dangerous functions with a whitelist, which means that on demand restricting should by default always be enabled for dangerous functions with a whitelist.

I think I am going to add a new rule to the +1 system: people that voted +1 on an issue and didn't give feedback on the issue will be excluded from future votes. It is disappointing to see that only @an0n981 is giving feedback here (and contributes other things to this project, like a complete documentation page about the database).

[an0n981]

Confirm that withe/black listing now works as intended 👍

Also is it normal that there are commits to review the code changes for this?

[M66B]

Thanks for the feedback.

You can review all commits if you like:
https://github.com/M66B/XPrivacy/commits/master

If you meant if somebody is reviewing my commits: not that I know of at the moment.
If you meant the commits were not contributed to this issue: my fault ;-)

[an0n981]

TYPO. I bad, I meant there were no commits prior to the new test version. I do review your commits (with my minimal java knowledge), just like I do all other open source xposed mods that I use.

[M66B]

I forgot to push them, but they are available now.

[Magissia]

M66B I will test XPrivacy on Defy mini (one core 700mhz, by head) when it's backported to Gingerbread if you want. I also have a TF101 using a dual core 1ghz, but don't know how far you classify devices as low end.

I'm sorry for not giving feedbacks sooner, i'm giving feedback when i can on the forum, you know it, i just don't always have the time to test the changes.

2 days delay to consider there's no feedback is a bit low in my own opinion.

Tell me if you want reports from back ported XPrivacy for gingerbread for very low end perforance, and i can make a test on the TF101 (4.4.2) for performance too if you consider it low end.

[M66B]

@Magissia one core 700 MHz would be an excellent test case. Please note that Gingerbread is not supported, the minimum Android version is 4.0.3 (ICS).

It is not that everybody has to give feedback, but just one person out of eleven giving feedback is quite meager, especially given that there was a call for feedback with a good reason.

[wbedard]

Feedback: It works fine. (Tested on 2012 Nexus 7 and Galaxy Nexus)

[Magissia]

Hello @M66B , i know Gingerbread is not supported, but it's the only low end device that i have, the bootloader is locked and no flaws was found to replace system. I will still test it but of course the performance will not only depend on your work, but on the work of the backporter too, i suppose that's better than nothing :)

[baleu]

Works great (2.0.25). Can't notice any performance issues on my Razr i (x86).

I get your frustration with too little feedback but I guess not everyone can check your test .apks's right away. Sometimes you have to do stuff that may be a bit more important ;)

I will always appreciate your work. XPrivacy is awesome.

[M66B]

This feature is part of the today released beta version 2.0.25

[an0n981]

Thanks again for this amazing feature!