Backlog issueshttps://gitlab.e.foundation/e/backlog/-/issues2024-02-07T13:56:01Zhttps://gitlab.e.foundation/e/backlog/-/issues/7699"Use assisted GPS" (A-GPS) contacts Google (supl.google.com) sharing approxim...2024-02-07T13:56:01ZBrewery"Use assisted GPS" (A-GPS) contacts Google (supl.google.com) sharing approximate location alongside IPI just read kuketz-blog.de [article](https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nicht-zwangslaeufig-sicher-custom-roms-teil6) about eOS.
According to it, at paragraph 4.5, if the user enable
`Settings > Location > Use ...I just read kuketz-blog.de [article](https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nicht-zwangslaeufig-sicher-custom-roms-teil6) about eOS.
According to it, at paragraph 4.5, if the user enable
`Settings > Location > Use assisted GPS`
approximate location is shared with supl.google.com alongside the user IP, in this way Google can associate the user (IP) with the location.
If it is not enabled, location is guessed through Mozilla Location Services.
In eOS this behaviour is not explained at all, with no warning when enabling assisted GPS, which I did since I had no idea Google was having my approximate location.
# solutions
The article states that grapheneOS has created a SUPL server proxy (supl.graphenos.org) that basically hide the user IP, so Google cannot associate it to the user. They also relies on PSDS files stored in their servers instead getting them from Google.https://gitlab.e.foundation/e/backlog/-/issues/7199Randomized MAC address option not available2024-03-01T14:12:50ZShenol MustafovRandomized MAC address option not available- /e/ version: 1.12
- Device model(s): FP3
- Developer mode enabled: yes/no
- Device rooted: yes/no
- Trackers blocker enabled: yes/no
## Summary
The option for using/not using randomised MAC adress, for each WiFi connection, is not av...- /e/ version: 1.12
- Device model(s): FP3
- Developer mode enabled: yes/no
- Device rooted: yes/no
- Trackers blocker enabled: yes/no
## Summary
The option for using/not using randomised MAC adress, for each WiFi connection, is not available on Fairphone 3
## The problem
**Steps to reproduce**
settings> network&internet > internet> choose wifi > look at settings. Below network usage there should be "Privacy" , but it is not there for FP3.
**What is the current behavior?**
No such option.
**What is the expected correct behavior?**
The option should be there
## Technical informations
**Relevant logs (`adb logcat`)**
<Paste any relevant logs in the codeblock bellow>
```
```
**Relevant screenshots**
<Screenshots of the problem>
## Solutions
**Workaround**
<To get the feature working or at least to make the device usable>
**Possible fixes**
<Any idea to fix the issue or a link to the line of code that might be the cause for this problem>
<Add the labels corresponding to your issue by adding a tilde and typing the name of the label you think apply to your issue in the line above. You need to type a tilde before the name of each label you want to apply to the issue.>https://gitlab.e.foundation/e/backlog/-/issues/6972Phone informations ping google servers2023-09-13T16:16:34ZHakim LarabiPhone informations ping google servers- /e/ version: 1.11S
- Device model(s): OP8T - kebab
## Summary
When accessing phone informations by composing `*#*#4636#*#*` the system pings google servers.
## Description
**What is the current behavior?**
Ping to the google serv...- /e/ version: 1.11S
- Device model(s): OP8T - kebab
## Summary
When accessing phone informations by composing `*#*#4636#*#*` the system pings google servers.
## Description
**What is the current behavior?**
Ping to the google servers google.com
**What is the improved behavior?**
Replace the google server link by quad9 IPs which is privacy safe and has 99.999% uptime. If possible please set the IP to avoid DNS resolution.
IPv4: `9.9.9.9`
```
➜ dig A dns.quad9.net +short
149.112.112.112
9.9.9.9
```
IPv6: `2620:fe::fe`
```
➜ dig AAAA dns.quad9.net +short
2620:fe::9
2620:fe::fe
```
**What does it bring?**
Full Degoogling system, with a ping to
| default | with ping done |
| ------ | ------ |
| ![Capture_d_écran_du_2023-05-25_09-43-36](/uploads/a064ee72645d0cc9a07891cc7e96f0e1/Capture_d_écran_du_2023-05-25_09-43-36.png) | ![Capture_d_écran_du_2023-05-25_09-43-50](/uploads/cd9c91b4753924f5296cd7b75e845c34/Capture_d_écran_du_2023-05-25_09-43-50.png) |/e/OS v1.14-betaMohammed Althaf ThayyilMohammed Althaf Thayyilhttps://gitlab.e.foundation/e/backlog/-/issues/6646Remove ping to Google server2024-02-09T02:03:55ZMax NRemove ping to Google server## Summary
When you want/need sometimes to debug Wifi/data connection, you can use the phone info you can access dialing `*#*#4636#*#*`
But when you go in some part of this tool, you will easily see that you can do ping to … google serv...## Summary
When you want/need sometimes to debug Wifi/data connection, you can use the phone info you can access dialing `*#*#4636#*#*`
But when you go in some part of this tool, you will easily see that you can do ping to … google server…
The idea is to replace google server by another one more private
Feature proposed in /e/ Community: https://community.e.foundation/t/feature-proposal-remove-ping-to-google-server/46853
## Description
**What is the feature?**
When you want/need sometimes to debug Wifi/data connection, you can use the phone info you can access dialing `*#*#4636#*#*`
But when you go in some part of this tool, you will easily see that you can do ping to … google server…
![image](/uploads/ed64314e73923a6f44f739834a8e2e7c/image.png) ![image](/uploads/3e69c40e54a6b51d9df2f972209a72b5/image.png)
The feature is just to replace the google server by another one more private (why not murena or one of a partner proposing privacy by design product (Qwant, Proton, Olvid, ...))
**Who will use this new feature?**
Any user who would need to debug connection issue with his phone
**Why these users would like to use this feature?**
I know that you can use a terminal to do the same and choose another server and that this ping function won’t be used by so many people but since we promote an ungoogled OS, I would say it would be good to avoid to use ping to Google’s servers, even for debugging purpose.
## Examples
to debug connection issue with his phone in order to avoid to use a terminal to ping another server which is not google
## Reflection
**Mockups**
**Diagrams**
## Validation
open the screen to debug connection and test the ping to the new added server which replaces google's one
~"type::Feature Proposal"
<Add the labels corresponding to your issue by adding a tilde and typing the name of the label you think apply to your issue in the line above. You need to type a tilde before the name of each label you want to apply to the issue.>https://gitlab.e.foundation/e/backlog/-/issues/6335Voice recorder app requires permission to "make and manage phone calls"2023-03-14T13:50:23ZShenol MustafovVoice recorder app requires permission to "make and manage phone calls"- /e/ version: 1.5
- Device model(s): all
- Device rooted: no
## Summary
Voice recorder app requires permission to “make and manage phone calls”, although this seems unnecessary.
## The problem
**Steps to reproduce**
Simply start th...- /e/ version: 1.5
- Device model(s): all
- Device rooted: no
## Summary
Voice recorder app requires permission to “make and manage phone calls”, although this seems unnecessary.
## The problem
**Steps to reproduce**
Simply start the Recorder for the first time, it will ask for this permission. If you disable the permission, it won't work.
**What is the current behavior?**
“make and manage phone calls” permission is required, and the app does not work without it
**What is the expected correct behavior?**
Access to the microphone should be sufficient. Microphone permission when granted, but not sufficient.
## Technical informations
<Add the labels corresponding to your issue by adding a tilde and typing the name of the label you think apply to your issue in the line above. You need to type a tilde before the name of each label you want to apply to the issue.>/e/OS v1.9-beta.2Mohammed Althaf ThayyilMohammed Althaf Thayyilhttps://gitlab.e.foundation/e/backlog/-/issues/5918murena.io Nextcloud rated F?2022-11-24T06:44:09ZGhost Usermurena.io Nextcloud rated F?Why does the cloud server get such a bad rating on my request? Is the data there secure?
![Screenshot_20220811-094329_Browser](/uploads/9c7b0ebf150bfa46c97917ece9643cbb/Screenshot_20220811-094329_Browser.png)Why does the cloud server get such a bad rating on my request? Is the data there secure?
![Screenshot_20220811-094329_Browser](/uploads/9c7b0ebf150bfa46c97917ece9643cbb/Screenshot_20220811-094329_Browser.png)https://gitlab.e.foundation/e/backlog/-/issues/5559Device connects to suspicious domains after v1 update2023-06-09T15:17:41ZPixelcodeDevice connects to suspicious domains after v1 update- /e/ version: 1.0-r-20220526188878-dev-FP3
- Device model(s): Fairphone 3
- Device rooted: no
I use Blokada as a system-wide ad/tracking blocker. After updating to /e/ OS v1.0 I noticed that the device regularly connects to different s...- /e/ version: 1.0-r-20220526188878-dev-FP3
- Device model(s): Fairphone 3
- Device rooted: no
I use Blokada as a system-wide ad/tracking blocker. After updating to /e/ OS v1.0 I noticed that the device regularly connects to different suspicious domains which all contain the string `localhost`. Since Blokada does not display which app made the requests, I cannot tell (yet) whether this is actually a problem of /e/ OS or rather some third-party app. However, it is very suspicious that these requests only appeared after the update.
I'm currently running the NetGuard firewall which does in fact show which app made a request. However, I haven't noticed another suspicious request yet.
Here's a screenshot of Blokada's activity log:
![suspicious_domains_eOS_2](/uploads/154085c7372a879ae18b2800f1307abe/suspicious_domains_eOS_2.png)
Here are all of the suspicious domains that I noticed:
```
localhost.com
localhost.de
localhost0
localhost1\009vs
localhost610
localhost670
localhost=wlan0
localhost_code
localhost_name
localhostab.net
localhostail.de
localhostal.org
localhostam.de
localhostatus
localhostb.com
localhostde
localhoste
localhoste\009&s
localhostel.de
localhosten.eu
localhostess
localhostex.io
localhostfo
localhostgs
localhosthain
localhosti.com
localhisticit
localhostit.com
localhostive
localhostllrule
localhostm
localhostme
localhostmer
localhostn.net
localhostnx.net
localhosto-usr
localhosto.com
localhostobal
localhostp.net
localhostply
localhostrg
localhostrv.com
localhostsocial
localhoststats
localhostsys
localhostsysme
localhostsysn
localhostsyso
localhostsysom
localhostsysorg
localhostsyss
localhostsyst
localhostt.com
localhostte.org
localhostter
localhostter.ms
www.localhost.de
```2023-01-06https://gitlab.e.foundation/e/backlog/-/issues/5513Investigate data leak on eCloud2022-06-06T07:10:03ZManoj NairInvestigate data leak on eCloud- /e/ version: All
- Device model(s): All
- Device rooted: yes/no NA
## Summary
On 29 May a couple of users reported they were able to view data from other accounts in their eCloud
## The problem
**Steps to reproduce**
Contact and co...- /e/ version: All
- Device model(s): All
- Device rooted: yes/no NA
## Summary
On 29 May a couple of users reported they were able to view data from other accounts in their eCloud
## The problem
**Steps to reproduce**
Contact and collect details of issue from impacted users
**What is the current behavior?**
A few users (approx 5% of users) were able to view data from other accounts.
**What is the expected correct behavior?**
User data should not be visible across accounts.
## Technical information
**Relevant logs (`adb logcat`)**
Issue was first reported on [the forum](https://community.e.foundation/t/service-announcement-26-may/41252/8)
```
```
**Relevant screenshots**
<Screenshots of the problem>
## Solutions
**Workaround**
<To get the feature working or at least to make the device usable>
**Possible fixes**
<Any idea to fix the issue or a link to the line of code that might be the cause for this problem>Arnau Vàzquezarnauvp@murena.ioArnau Vàzquezarnauvp@murena.iohttps://gitlab.e.foundation/e/backlog/-/issues/5214Connections to Google detected on App Lounge2022-10-11T16:59:20ZManoj NairConnections to Google detected on App Lounge- /e/ version: v0.23
- Device model(s): All
- Device rooted: yes/no No
## Summary
User reports connections to google servers from ~"app lounge"
## The problem
**Steps to reproduce**
Issue as reported by user on the forum
I see t...- /e/ version: v0.23
- Device model(s): All
- Device rooted: yes/no No
## Summary
User reports connections to google servers from ~"app lounge"
## The problem
**Steps to reproduce**
Issue as reported by user on the forum
I see the connections in the Blokada 5 tracker-blocking app. Besides the usual mtalk.google.com, which if I’m not mistaken is unavoidable, even on /e/, Blokada noted all these:
Opening App Lounge, a connection is made to clients3.google.com and android.clients.google.com.
Selecting Anonymous Login within the app triggers a connection to play-lh.googleusercontent.com.
Checking for updates to installed apps, calls clients3.google.com again.
Clicking to App Lounge Home sends android.clients.google.com again.
Searching for a specific app calls play-lh.googleusercontent.com again.
Opening the landing page of the searched-for app sends to clients3.google.com again.
Clicking on a category, e.g. “Medical,” within the Categories tab calls clients3.google.com again.
Clicking on Terms of Service calls clients3.google.com again.
Closing the app calls clients3.google.com again.
I was connected to my home WiFi during this test, but interestingly, my Pi-hole application didn’t register a single one of these. (Only mtalk.google.com.)
I’m not qualified to say if these represent anything nefarious or exploitative, but I instinctively distrust any connection to a Google domain, so I would be appreciative of any clarification.
**What is the current behavior?**
As reported above
**What is the expected correct behavior?**
No connections to google
## Technical information
**Relevant logs (`adb logcat`)**
<Paste any relevant logs in the codeblock bellow>
```
```
**Relevant screenshots**
<Screenshots of the problem>
Link to the [original issue](https://community.e.foundation/t/app-lounge-data-privacy-from-google/40001/6)
## Solutions
**Workaround**
<To get the feature working or at least to make the device usable>
**Possible fixes**
<Any idea to fix the issue or a link to the line of code that might be the cause for this problem>https://gitlab.e.foundation/e/backlog/-/issues/4648FP3+ R 0.21: "Private DNS" is not always working (DoH or DoT)2023-06-01T01:03:30ZLukas MayrFP3+ R 0.21: "Private DNS" is not always working (DoH or DoT)- /e/ version: 0.21-r-20220113156964-dev-FP3
- Device model(s): FP3+ (Upgraded camera modules)
- Device rooted: No
## Summary
- If I set the "DNS" and "Private DNS" settings for some DNS providers with DoH and DoT it is not possible to...- /e/ version: 0.21-r-20220113156964-dev-FP3
- Device model(s): FP3+ (Upgraded camera modules)
- Device rooted: No
## Summary
- If I set the "DNS" and "Private DNS" settings for some DNS providers with DoH and DoT it is not possible to connect to the internet.
## The problem
- Settings > Network and Internet > DNS > Set DNS to use: Enter the IP address
- Settings > Network and Internet > Private DNS > Private DNS provider hostname: Enter the hostname
<How one can reproduce the issue>
**1. Internet not working**:
- DNS: 5.1.66.255
- Private DNS: dot.ffmuc.net or doh.ffmuc.net ("Couldn't connect")
- Link: https://ffmuc.net/wiki/doku.php?id=knb:dohdot#android_9
- ...
- DNS: 208.67.222.222
- Private DNS: doh.opendns.com ("Couldn't connect")
- Link: https://support.opendns.com/hc/en-us/articles/360038086532-Using-DNS-over-HTTPS-DoH-with-OpenDNS
**2. Internet working**:
- DNS: 1.1.1.1
- Private DNS: 1dot1dot1dot1.cloudflare-dns.com
- Link: https://blog.cloudflare.com/enable-private-dns-with-1-1-1-1-on-android-9-pie/
- ...
- DNS: 8.8.8.8
- Private DNS: dns.google
- Link: https://developers.google.com/speed/public-dns/docs/dns-over-tls
- ...
- DNS: 9.9.9.9
- Private DNS: dns.quad9.net
- Link: https://www.quad9.net/news/blog/enable-private-dns-using-quad9-on-android-9/
<What actually happens>
It should be possible to connect via DoH or DoT to Freifunk München (dot.ffmuc.net or doh.ffmuc.net) or to OpenDNS (doh.opendns.com) or to other DNS providers with DoH or DoT.
<What you should see instead>
## Technical informations
**Relevant logs (`adb logcat`)**
<Paste any relevant logs in the codeblock bellow>
```
```
**Relevant screenshots**
<Screenshots of the problem>
## Solutions
**Workaround**
- Workaround is to use a provider which you don't like: E. g. Google, etc.
<To get the feature working or at least to make the device usable>
**Possible fixes**
- I think it should be possible to enter a full URL into the "Private DNS" field. It's not possible to save the changes when I enter https://...
<Any idea to fix the issue or a link to the line of code that might be the cause for this problem>https://gitlab.e.foundation/e/backlog/-/issues/4637NTP servers are set as null2022-01-29T10:08:30ZManoj NairNTP servers are set as null- /e/ version: R
- Device model(s): ~FP4
- Device rooted: yes/no No
## Summary
NTP servers default value is not set
## The problem
**Steps to reproduce**
Run the below adb commands
`adb shell 'settings get global captive_portal_h...- /e/ version: R
- Device model(s): ~FP4
- Device rooted: yes/no No
## Summary
NTP servers default value is not set
## The problem
**Steps to reproduce**
Run the below adb commands
`adb shell 'settings get global captive_portal_https_url'`
`adb shell settings get global ntp_server`
**What is the current behavior?**
null is being returned
**What is the expected correct behavior?**
The value `pool.ntp.org` should be set as default
## Technical informations
**Relevant logs (`adb logcat`)**
<Paste any relevant logs in the codeblock bellow>
```
```
**Relevant screenshots**
<Screenshots of the problem>
## Solutions
**Workaround**
<To get the feature working or at least to make the device usable>
**Possible fixes**
<Any idea to fix the issue or a link to the line of code that might be the cause for this problem>Abhishek AggarwalAbhishek Aggarwalhttps://gitlab.e.foundation/e/backlog/-/issues/4412Google apps found in /e/ system on Essential PH-1 (mata)2023-11-19T02:03:27ZChris RandGoogle apps found in /e/ system on Essential PH-1 (mata)- /e/ version: Test builds e-0.19-r-20211030143465-dev-mata.zip & e-0.20-q-20211208150509-dev-mata.zip
- Device model(s): mata
- Device rooted: no
## The problem
Three google apps are present on the device as system apps.
The package ...- /e/ version: Test builds e-0.19-r-20211030143465-dev-mata.zip & e-0.20-q-20211208150509-dev-mata.zip
- Device model(s): mata
- Device rooted: no
## The problem
Three google apps are present on the device as system apps.
The package names are:
com.android.hotwordenrollment.okgoogle, com.android.hotwordenrollment.tgoogle & com.android.hotwordenrollment.xgoogle
I became aware of this after reading a forum post where another user had noticed google apps on a new installation on a OnePlus 7T hotdogb.
https://community.e.foundation/t/google-assistant-listed-in-e-system-apps/37093
**Relevant logs (`adb logcat`)**
<Paste any relevant logs in the codeblock bellow>
```
```
**Relevant screenshots**
<Screenshots of the problem>![photo_2021-12-11_09-59-17.resized](/uploads/9ad3ff13555478e804f59535dff97076/photo_2021-12-11_09-59-17.resized.jpg)
## Solutions
**Workaround**
<To get the feature working or at least to make the device usable>
**Possible fixes**
<Any idea to fix the issue or a link to the line of code that might be the cause for this problem>https://gitlab.e.foundation/e/backlog/-/issues/4091Secure App Installer based on nervuris suggestions2022-10-30T02:03:45ZManoj NairSecure App Installer based on nervuris suggestions- /e/ version: All
- Device model(s): All
- Device rooted: yes/no NA
## Summary
nervuri has pointed out issues in the App Installer
## The problem
**Steps to reproduce**
The issues in the App Installer code are pointed out in this [t...- /e/ version: All
- Device model(s): All
- Device rooted: yes/no NA
## Summary
nervuri has pointed out issues in the App Installer
## The problem
**Steps to reproduce**
The issues in the App Installer code are pointed out in this [thread on the forum](https://community.e.foundation/t/an-analysis-of-the-e-os-app-installer/35802).
**What is the current behavior?**
Existing App Installer code needs to be improved
**What is the expected correct behavior?**
Refer these threads for more details
[On the forum](https://community.e.foundation/t/an-analysis-of-the-e-os-app-installer/35802)
[Detailed analysis on the nervuri site](https://nervuri.net/e/apps)
## Technical informations
**Relevant logs (`adb logcat`)**
<Paste any relevant logs in the codeblock bellow>
```
```
**Relevant screenshots**
<Screenshots of the problem>
## Solutions
**Workaround**
<To get the feature working or at least to make the device usable>
**Possible fixes**
<Any idea to fix the issue or a link to the line of code that might be the cause for this problem>https://gitlab.e.foundation/e/backlog/-/issues/3650Weather widget leaks the user location2022-08-04T08:09:46ZtcecykWeather widget leaks the user location- /e/ version: current v0.18
- Device model(s): all
- Device rooted: yes/no
## Summary
Update endpoints to HTTPS as in upstream PR https://github.com/qqq3/good-weather/pull/41
(I'm aware Good Weather is no longer (v0.16 or 17?) in the...- /e/ version: current v0.18
- Device model(s): all
- Device rooted: yes/no
## Summary
Update endpoints to HTTPS as in upstream PR https://github.com/qqq3/good-weather/pull/41
(I'm aware Good Weather is no longer (v0.16 or 17?) in the default apps)
The proposal was made by the Author of DivestOS in a thread at https://community.e.foundation/t/divestos-vs-e-os-security-and-privacy-easy/33717/67
## The problem
**Steps to reproduce**
Run the weather app, look at Wireshark. As location is essential for weather requests, the contents of the request shouldn't be disclosed.
**What is the current behavior?**
the HTTP endpoints of the weather service are used
**What is the expected correct behavior?**
use the HTTPS API
## Technical informations
checking in on https://gitlab.e.foundation/e/apps/Weather/-/blob/master/app/src/main/java/foundation/e/weather/utils/Constants.java HTTP endpoints are used. Should be an easy straightforward patch. I don't understand why it's not merged upstream.. probably because of work on the original qqq3/good-weather stopped (only few merges in 2017, then stopped) and moved on to your-local-weather.
## Alternative
In [your-local-weather App](https://f-droid.org/packages/org.thosp.yourlocalweather/) https endpoints are used, so an alternative solution is to rebase the /e/ fork to this app https://github.com/thuryn/your-local-weather/blob/master/app/src/main/java/org/thosp/yourlocalweather/utils/Constants.java/e/OS v1.2-betaSuphon ThanakornpakapongSuphon Thanakornpakaponghttps://gitlab.e.foundation/e/backlog/-/issues/3432hide or fake network data2022-09-02T01:03:50ZJohn Smithhide or fake network data## Summary
Support an app like XPrivacyLua or provide such functionality. Currently when I try to install [XPrivacyLua](https://github.com/M66B/XPrivacyLua), it says device not supported. Maybe it's not needed at all but I don't know.
...## Summary
Support an app like XPrivacyLua or provide such functionality. Currently when I try to install [XPrivacyLua](https://github.com/M66B/XPrivacyLua), it says device not supported. Maybe it's not needed at all but I don't know.
## Description
**Who will use the new feature?**
Anyone interested in buying a degoogled phone.
**What is the target of the new feature for this user?**
XPrivacyLua can act complementary to the current [App permissions](https://community.e.foundation/t/app-permissions/13304) as it can hide/fake:
1. cell info
2. Wi-Fi network name
3. IMEI, SIM serial number
4. network/SIM country/operator
and the following that might not be applicable to /e/:
1. [activity](https://developers.google.com/location-context/activity-recognition)
2. [account email](https://developer.android.com/reference/android/accounts/Account)
3. [build properties](https://developer.android.com/reference/android/os/Build.html)
**Why this user would like to use this feature?**
To reduce the chance of being identified by [spoofing a digital fingerprint](https://en.wikipedia.org/wiki/Device_fingerprint#Offering_a_spoofed_fingerprint). If there is an app that can put not a random fake value but the most common value even for specific fingerprints only, even better so that the user won't have to find our (or usually guess) the most common value.
I wouldn't suggest changing fake values frequently.
## Examples
If you provide such functionality yourself, the "Additional permissions" screen of "Permission manager" could have an entry called "Network Data" for the first 4 items above.
## Reflection
**Mockups**
**Diagrams**
## Validation
<List test case that will be run to validate that the issue is working as expected>https://gitlab.e.foundation/e/backlog/-/issues/3044`Touch to search` sends data to Google site2021-06-24T04:16:23ZManoj Nair`Touch to search` sends data to Google site- /e/ version: All
- Device model(s): All
## Summary
Touch to search option under browser shows an option to send data to Google
## The problem
**Steps to reproduce**
- OpenBrowser - Three menu menu (top right) - Settings - Privacy...- /e/ version: All
- Device model(s): All
## Summary
Touch to search option under browser shows an option to send data to Google
## The problem
**Steps to reproduce**
- OpenBrowser - Three menu menu (top right) - Settings - Privacy and Security - Touch to Search
**What is the current behavior?**
This opens a screen which offers to send data to Google servers.
**What is the expected correct behavior?**
The send to Google servers should not be available on a de-googled OS
## Technical informations
**Relevant logs (`adb logcat`)**
<Paste any relevant logs in the codeblock bellow>
```
```
**Relevant screenshots**
![Screenshot_20210424-042055_Browser](/uploads/3559717b9942ce783f2a6fe1103a7a68/Screenshot_20210424-042055_Browser.png)
## Solutions
**Workaround**
<To get the feature working or at least to make the device usable>
**Possible fixes**
<Any idea to fix the issue or a link to the line of code that might be the cause for this problem>/e/OS v0.18Aayush Guptatheimpulson@e.emailAayush Guptatheimpulson@e.emailhttps://gitlab.e.foundation/e/backlog/-/issues/2854X Google Enrollment / OK Google Enrollment2022-11-28T07:57:46ZRalph BöhlkeX Google Enrollment / OK Google Enrollment- /e/ version: 0.15-Q
- Device model(s): Beryllium
## Summary
I found 2 pieces of Google software on my device, I suppose it should not be there.
On Beryllium it could be found, on FP3 not.
So, I suppose is less likely a Q-specific is...- /e/ version: 0.15-Q
- Device model(s): Beryllium
## Summary
I found 2 pieces of Google software on my device, I suppose it should not be there.
On Beryllium it could be found, on FP3 not.
So, I suppose is less likely a Q-specific issue, rather a device specific one.
![214-okgoogleenrollment](/uploads/8aec591f9789d051a4b0db1222be7381/214-okgoogleenrollment.jpg)/e/OS v1.6-betaDaniel Jacob ChittoorDaniel Jacob Chittoorhttps://gitlab.e.foundation/e/backlog/-/issues/2794Feature request for improving app privacy by isolating apps2023-03-17T02:03:23ZGhost UserFeature request for improving app privacy by isolating apps## Summary
Hi, I would like to propose a new feature that can improve users privacy by isolating apps so they cannot access other apps usage data and stored information.
## Description
There is an existing functionality in Android si...## Summary
Hi, I would like to propose a new feature that can improve users privacy by isolating apps so they cannot access other apps usage data and stored information.
## Description
There is an existing functionality in Android since android 10, and that is Work profiles. So what this does is, it creates a separate profile or container for apps that cannot access main profile and has their own compartments to store and access data. Using this built-in feature, some apps like Island which is still in development phase can create isolated installations of apps. But the problem is, it does not work great, neither we can manage the isolated apps in good manner.
So if /e/OS can implement it with better controls and management, it can turn out to be a great feature for /e/OS which will make /e/OS stand apart and more private.
### So why this is important?
Some of the users needs to use apps such as Facebook for business case. There are tons of other apps that are privacy invasive yet we are forced to use for business purpose or other causes. This may help users use apps without them recording usage data. Because each container will contain a single app with no data in it except its own data, it cannot record usage data, collect contact info or access other kind of data.
## Examples
1. User has to use an app for a business task
2. That app is privacy invasive and wont run until all the permissions are given
3. Users forces to give away data in returns for important use case
4. /e/OS gives an option to workaround this with isolated installation
5. User install this app from the App Store with the "Prevent this app from accessing your data" option checked
6. When installed from an APK file, /e/OS also prompts if user want to use an option labeled "Prevent this app from accessing your data"
7. If the app is already installed, there is an option to move that app in isolated container
8. User now installs it in isolated mode and can use it without the fear of the app collecting sensitive data
9. User is now happy
## Resources and technical points
Android started rolling out Work profiles from version 5.0 (API lvl-22) but it came out with more polishes and improvement in Android 9+. So majority of the devices have work profiles built in that can be used as base to create a management tool on top of it. See Android documentation on [work profile](https://developer.android.com/work/managed-profiles). There is also an YouTube video explaining ways to [build apps for work profile](https://www.youtube.com/watch?v=QHOo8zTYRzk).
The main intention of Work profile is to ensure safety of enterprise data such as organization controlled apps, confidential data etc. But it can be used not only for enterprise use case, but also for protecting users privacy in general circumstances. There are apps using it to provide isolated app installation for privacy protection. It can also be used for cloning apps, used by Parallel and similar apps.
I recently stumbled upon a nice read which I will [link here](https://code.mendhak.com/run-apps-in-privacy-shelter/). There is another app that is similar to this, but with different set of features you can check [from here](https://play.google.com/store/apps/details?id=com.oasisfeng.island&hl=en&gl=US).
## Reflection
I will soon add a mockup or a wireframe of an examplehttps://gitlab.e.foundation/e/backlog/-/issues/2568Q dialer is asking for location access2023-12-11T17:18:26ZRalph BöhlkeQ dialer is asking for location access- /e/ version: 0.14-q
- Device model(s): Beryllium + FP3
https://gitlab.e.foundation/e/backlog/-/issues/2140
## Summary
The dialer in Android Q is an upgraded version. When clicking on the top bar (search contacts, IMG-1), a windows ...- /e/ version: 0.14-q
- Device model(s): Beryllium + FP3
https://gitlab.e.foundation/e/backlog/-/issues/2140
## Summary
The dialer in Android Q is an upgraded version. When clicking on the top bar (search contacts, IMG-1), a windows is popping up asking for location access (To get contact information for places near you, allow access to your location", IMG-2)
This is a functionality where I am not sure if it is desirable within an eOS/privacy context.
This function should be removed or deserves at least further explaination.
There are 2 more issues within the same new dialer that had already been reported:
- Voice Search Icon (https://gitlab.e.foundation/e/backlog/-/issues/2140)
- ToS and PP to be degoogled (https://gitlab.e.foundation/e/backlog/-/issues/2139)
**Relevant screenshots**
![201-dialerQ-sharelocation-1](/uploads/1be71806a0647f839f01f3904ce5b603/201-dialerQ-sharelocation-1.jpg)
![202-dialerQ-sharelocation-2](/uploads/13b49d6bb51b816451fd592341449013/202-dialerQ-sharelocation-2.jpg)https://gitlab.e.foundation/e/backlog/-/issues/2516Result of privacy check of apps is faulty2022-06-22T10:21:13ZArmin ScribaResult of privacy check of apps is faulty- /e/ version: 0.13-2020121590522, Android 10
- Device model(s): GS290
## Summary
The results of the privacy check of apps shows always "10" for trackers, though trackers are listed if you click "trackers".
The shown colors seem to be ...- /e/ version: 0.13-2020121590522, Android 10
- Device model(s): GS290
## Summary
The results of the privacy check of apps shows always "10" for trackers, though trackers are listed if you click "trackers".
The shown colors seem to be randomly picked and do not correspond to Exodus privacy or the rating.
For me this is a very important function on /e/OS.
## The problem
**Steps to reproduce**
Go to app store and open an app. Below the description the privacy check via Exodus privacy shows the "rating" of the app (Berechtigung / Tracker (permissions / trackers)).
**What is the current behavior?**
Tracker is always rated with 10, colors seem to be randomly picked.
**What is the expected correct behavior?**
Tracker rating should correspond to real number of trackers.
Colors should show rating / weighing of the permissions and trackers.
## Technical informations
**Relevant logs (`adb logcat`)**
none
**Relevant screenshots**
![image](/uploads/259f9d0069aa4cb6c5835acca48ab5fe/image.png)
## Solutions
**Workaround**
Check app via Exodus privacy directly.
**Possible fixes**
I expect a transfer problem between Exodus and /e/.