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/291/e/ Forum search defaults to Google2021-03-29T13:04:34ZManoj Nair/e/ Forum search defaults to Google# The /e/ search defaults to Google
## Summary
The /e/ search defaults to Google
## Steps to reproduce
- Log in to the e community forum https://community.e.foundation/
- Search any vague term
- The search result page asks to search o...# The /e/ search defaults to Google
## Summary
The /e/ search defaults to Google
## Steps to reproduce
- Log in to the e community forum https://community.e.foundation/
- Search any vague term
- The search result page asks to search on google
## What is the current behavior?
The search result page asks to search on google
## What is the expected correct behavior?
The search result page should not contain references to Google search and instead should show DuckDuckGo or the default /e/ search
## Relevant logs and/or screenshots
![Screenshot_from_2019-04-27_18-56-25](/uploads/575c4d4e850fb50a6c9d5894b173025d/Screenshot_from_2019-04-27_18-56-25.png)
## Possible fixes
(If you can, link to the line of code that might be the cause for this problem)
@rhunault please assign this issue to @manojnair as I would be working on resolving it.Manoj NairManoj Nairhttps://gitlab.e.foundation/e/backlog/-/issues/948/e/ vulnerability pin and fingerprint2023-04-06T01:03:32ZGhost User/e/ vulnerability pin and fingerprintDeleting the following files (using adb or TWRP) removes pin and fingerprint:
```
/data/system/locksettings.db
/data/system/users/0/fpdata/user.db
/data/system/users/0/settings_fingerprint.xml
```Deleting the following files (using adb or TWRP) removes pin and fingerprint:
```
/data/system/locksettings.db
/data/system/users/0/fpdata/user.db
/data/system/users/0/settings_fingerprint.xml
```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/259All /e/ address books are publicly available2019-09-30T14:09:32ZSupermanAll /e/ address books are publicly available## Summary
All /e/ address books are publicly available
## Steps to reproduce
open https://ecloud.global/apps/rainloop/
write a new email
in field ‘To:’ start to type something ‘al’ by example
## What is the current behavio...## Summary
All /e/ address books are publicly available
## Steps to reproduce
open https://ecloud.global/apps/rainloop/
write a new email
in field ‘To:’ start to type something ‘al’ by example
## What is the current behavior?
All contacts from all /e/ user’s address book containing ‘al’ are suggested
## What is the expected correct behavior?
Only contacts from my address books should be suggestedthiloFelixthilohttps://gitlab.e.foundation/e/backlog/-/issues/1422Calls home when connected to private DNS2023-04-20T01:03:34ZAndré LamCalls home when connected to private DNS- /e/ version: Pie custom build
- Device model: S2/FP3
- When it started to occur: always
- Reproducible with the last /e/ version: -
- Reproducible with LineageOS: -
## Summary
I see calls home on custom Pie build. Tested Leeco s2 with...- /e/ version: Pie custom build
- Device model: S2/FP3
- When it started to occur: always
- Reproducible with the last /e/ version: -
- Reproducible with LineageOS: -
## Summary
I see calls home on custom Pie build. Tested Leeco s2 with only system apps installed. I see it also on FP3 custom build, but i use it as daily driver and i have other Apps installed.
- [X] The device is unusable
- [ ] The bug is the source of a data loss or a big waste of time
- [ ] The bug concerns a third party app
- [ ] The bug concerns security
- [X] The bug concerns privacy
## The problem
There are calls to Google when toggling wifi on/off.
**Steps to reproduce**
Use a Pie version of /e/, set a private DNS, i recommend nextdns.io because it's free and you can see logs.
<How one can reproduce the issue>
Toggle wifi on/off, and go to nextdns log page to see the calls to Google
**What is the current behavior?**
Calls to Google.
**What is the expected correct behavior?**
No calls to Google.
## Technical informations
I can't use the official /e/ for Leeco S2 becaue Pie does not exist for it, and in Nougat private DNS is not available.
**Relevant screenshots**
![dns-bl2](/uploads/c911cd762eaaea7778b8e0f04c8aca42/dns-bl2.png)
## Solutions
?https://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/35Consider Maps.ME2021-01-13T06:52:58ZSreehari SConsider Maps.MEMaps.me uses OpenStreetMaps, and is open source. Plus, the UI looks nice. Why don't you guys consider this (or a fork of this) as the maps app for /e/?Maps.me uses OpenStreetMaps, and is open source. Plus, the UI looks nice. Why don't you guys consider this (or a fork of this) as the maps app for /e/?https://gitlab.e.foundation/e/backlog/-/issues/15Data Leak from Dialler to google2020-08-03T09:30:09ZkurtnData Leak from Dialler to googleDialler > Settings(threedot) > Phone number lookup The Default "Forward lookup Provider" is GoogleDialler > Settings(threedot) > Phone number lookup The Default "Forward lookup Provider" is Googlehttps://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/1032Disable Forward lookup2020-04-27T17:25:23ZRomain HunaultDisable Forward lookup## Summary
<Summarize the improvement briefly and precisely>
**This improvement concerns** <Tick at least one of the following choices>
- [ ] UI
- [ ] Behavior
- [x] Privacy
## Description
**What is the current behavior?**
<What act...## Summary
<Summarize the improvement briefly and precisely>
**This improvement concerns** <Tick at least one of the following choices>
- [ ] UI
- [ ] Behavior
- [x] Privacy
## Description
**What is the current behavior?**
<What actually happens>
The **forward lookup** setting is enabled by default in the Dialer
**What is the improved behavior?**
<What you should see instead>
The **forward lookup** setting is disabled by default
**What does it bring?**
Privacy (don't send data to a third party by default)
<Why this improvement is needed>
## Examples
<Give the example of what users will be able to accomplish with the improvement>
## Validation
<List test case that will be run to validate that the issue is working as expected>
Install /e/ and check that **forward lookup** is disabled by default, inside Dialer Settings.
Ideally, it should also be disabled after an update.
FYI @arnauvp @gaelJalon-JabugoMohit MaliMohit Malihttps://gitlab.e.foundation/e/backlog/-/issues/1033Disable Reverse Lookup2020-04-27T19:09:42ZRomain HunaultDisable Reverse Lookup## Summary
<Summarize the improvement briefly and precisely>
**This improvement concerns** <Tick at least one of the following choices>
- [ ] UI
- [ ] Behavior
- [x] Privacy
## Description
**What is the current behavior?**
<What act...## Summary
<Summarize the improvement briefly and precisely>
**This improvement concerns** <Tick at least one of the following choices>
- [ ] UI
- [ ] Behavior
- [x] Privacy
## Description
**What is the current behavior?**
<What actually happens>
The **reverse lookup** setting is enabled by default in the Dialer
**What is the improved behavior?**
<What you should see instead>
The **reverse lookup** setting is disabled by default
**What does it bring?**
Privacy (don't send data to a third party by default)
<Why this improvement is needed>
## Examples
<Give the example of what users will be able to accomplish with the improvement>
## Validation
<List test case that will be run to validate that the issue is working as expected>
Install /e/ and check that **reverse lookup** is disabled by default, inside Dialer Settings.
Ideally, it should also be disabled after an update.
FYI @arnauvp @gaelJalon-JabugoMohit MaliMohit Malihttps://gitlab.e.foundation/e/backlog/-/issues/189Discourse app depends on Google Chrome2020-02-26T19:15:46ZthiloDiscourse app depends on Google ChromeDiscourse app depends on Google Chrome and uses FCM/GCM
-> Not usabel without installing Chrome Stable -> Not usable at /e/ without neglecting the idea behind /e/.
I think that is being worked on already?Discourse app depends on Google Chrome and uses FCM/GCM
-> Not usabel without installing Chrome Stable -> Not usable at /e/ without neglecting the idea behind /e/.
I think that is being worked on already?https://gitlab.e.foundation/e/backlog/-/issues/637DNS Multiple entries (Set DNS to use configuration)2023-04-06T01:03:34ZbeletteDNS Multiple entries (Set DNS to use configuration)- /e/ version:
- Device model: Xiaomi M8
- Reproducible with the last /e/ version:Yes
- Reproducible with LineageOS:Not tested
## Summary
I have tried to put space or comma but only one DNS is used which is obviously too low.
**This i...- /e/ version:
- Device model: Xiaomi M8
- Reproducible with the last /e/ version:Yes
- Reproducible with LineageOS:Not tested
## Summary
I have tried to put space or comma but only one DNS is used which is obviously too low.
**This improvement concerns**
- [ ] UI
- [x] Behavior
- [ ] Privacy
## Description
**What is the current behavior?**
Not possible to set more than one DNS server
<What actually happens>
Setting more than one more server is failing back to '9.9.9.9"
**What is the improved behavior?**
Adding one more server to failover to a secondary server should be possible
<What you should see instead>
Option to set two IP servers (IPv4 or IPv6 or a mix)
**What does it bring?**
Resilient and failover
<Why this improvement is needed>
Should be the default behavior like most / all network based solution propose.
## Examples
Adding something like:
"A.A.A.A,B.B.B.B"
## Validation
Check IPv4/v6 validityhttps://gitlab.e.foundation/e/backlog/-/issues/1366Doesn't (re)connect to hidden SSID2021-01-20T12:49:52ZNickyDoesn't (re)connect to hidden SSID- /e/ version:
- Device model:
- When it started to occur:
- Reproducible with the last /e/ version:
- Reproducible with LineageOS:
## Summary
<Summarize the bug encountered briefly and precisely>
<Please tick one of the following sen...- /e/ version:
- Device model:
- When it started to occur:
- Reproducible with the last /e/ version:
- Reproducible with LineageOS:
## Summary
<Summarize the bug encountered briefly and precisely>
<Please tick one of the following sentences if relevant>
- [ ] The device is unusable
- [ ] The bug is the source of a data loss or a big waste of time
- [ ] The bug concerns a third party app
- [ ] The bug concerns security
- [x] The bug concerns privacy
## The problem
So I got my pairphone today, my SSID is hidden so I manual added my wifi. Phone won't connect. Then I disable hidden SSID setting in my router and the phone connects straight away. I enable hidden SSID again and wifi disconnects again. I have a Netgear R7000 with DD-wrt firmware. PS: I like the phone A LOT!! :)
**Steps to reproduce**
Hide your SSID from your modem, phone does not connect.
<How one can reproduce the issue>
**What is the current behavior?**
<What actually happens>
**What is the expected correct behavior?**
<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**
<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/1701eDrive - Files syncing with /e/ account removed from AccountManager2020-08-26T07:50:33ZShenol MustafoveDrive - Files syncing with /e/ account removed from AccountManager- /e/ version:
- Device model: Nexus 5X
- When it started to occur:
- Reproducible with the last /e/ version:
- Reproducible with LineageOS:
When you add an /e/ account everything syncs, but if you remove that account and add your own N...- /e/ version:
- Device model: Nexus 5X
- When it started to occur:
- Reproducible with the last /e/ version:
- Reproducible with LineageOS:
When you add an /e/ account everything syncs, but if you remove that account and add your own NextCloud account, it will sync contacts and calendars, but the files still sync with the deleted /e/ account.
I can get the phone to stop sending files by clearing the cache in the settings, but I could not get the files to sync with nextCloud. To ge NextCloud syncing, I had to delete all user data from the settings app, reboot the phone, then add the custom NextCloud account. Once I did that, now files properly sync to the custom NextCloud.
I think this is an important big because the phone is potentially still pushing files to a deleted account, and that is not good for a privacy-focused phone.
Likely, on deleting an account, the app is not cleaning relevant cache.
<Please tick one of the following sentences if relevent>
- [ ] The device is unusable
- [ ] The bug is the source of a data loss or a big waste of time
- [ ] The bug concerns a third-party application
- [X] The bug concerns security
- [X] The bug concerns privacy
* Issue was reported by Tom-STL <accountservices@switchedtolinux.com> - a journalist covering /e/
I do not have access to the phone he is using. I suggest someone with a Nexus 5X to replicate the issue. Alternatively we can reach him for questions.QuitoMohit MaliMohit Malihttps://gitlab.e.foundation/e/backlog/-/issues/1504enable /e/ account only for certain uses2021-04-24T17:35:11Zp0t4enable /e/ account only for certain uses- /e/ version: 0.9
- Device model: samsung s7 edge
- When it started to occur: since forever
- Reproducible with the last /e/ version:
- Reproducible with LineageOS:
## Summary
I have enabled an account /e/ only for notes (it is impossi...- /e/ version: 0.9
- Device model: samsung s7 edge
- When it started to occur: since forever
- Reproducible with the last /e/ version:
- Reproducible with LineageOS:
## Summary
I have enabled an account /e/ only for notes (it is impossible to use the app without an account) and contacts.
but I noticed that - once enabled - also all the images and various settings of the phone are automatically shared on the nextcloud of /e/.
I just want to use the notes and save some contacts. I don’t want to share everything in the cloud. is it possible?
I believe that if “your data is YOUR data” it is important to ensure that each application can work locally and disconnected from the cloud.
<Please tick one of the following sentences if relevant>
- [ ] The device is unusable
- [ ] The bug is the source of a data loss or a big waste of time
- [ ] The bug concerns a third party app
- [ ] The bug concerns security
- [*] The bug concerns privacy
## The problem
**Steps to reproduce**
<How one can reproduce the issue>
**What is the current behavior?**
<What actually happens>
**What is the expected correct behavior?**
<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**
<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/2311Enable MAC randomization on FP32023-08-20T01:24:49ZAndrea EEnable MAC randomization on FP3## Summary
Enable MAC randomization on the Fairphone 3 (FP3)
## Description
For context, see https://source.android.com/devices/tech/connect/wifi-mac-randomization
> Starting in Android 8.0, Android devices use randomized MAC address...## Summary
Enable MAC randomization on the Fairphone 3 (FP3)
## Description
For context, see https://source.android.com/devices/tech/connect/wifi-mac-randomization
> Starting in Android 8.0, Android devices use randomized MAC addresses when probing for new networks while not currently associated with a network. In Android 9, you can enable a developer option (it's disabled by default) to cause the device to use a randomized MAC address when connecting to a Wi-Fi network.
>
> In Android 10, MAC randomization is enabled by default for client mode, SoftAp, and Wi-Fi Direct.
>
> MAC randomization prevents listeners from using MAC addresses to build a history of device activity, thus increasing user privacy.
>
> Additionally, MAC addresses are randomized as part of Wi-Fi Aware and Wi-Fi RTT operations.
**Who will use the new feature?**
Any user will benefit from the enhanced privacy this feature provides.
**What is the target of the new feature for this user?**
Enhanced privacy.
**Why this user would like to use this feature?**
MAC randomization prevents listeners from using MAC addresses to build a history of device activity, thus increasing user privacy.
## Reflections
I am not completely sure that MAC randomization is supported by Fairphone 3 - this would need to be confirmed.
Cherry-picking this LineageOS commit might be all that is needed: https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/281640
## Validation
See https://source.android.com/devices/tech/connect/wifi-mac-randomization#validation for test cases.https://gitlab.e.foundation/e/backlog/-/issues/174Encryption not working2022-02-10T15:53:54ZHex MasteenEncryption not working# Encryption not successful.
## Summary
The encryption function reboots the phone but does not encrypt the partition (on tissot and possibly other devices). There is also no clear indication/warning that the encryption was not successfu...# Encryption not successful.
## Summary
The encryption function reboots the phone but does not encrypt the partition (on tissot and possibly other devices). There is also no clear indication/warning that the encryption was not successful.
## Steps to reproduce
1. Install `e-0.2-201811242083-nightly` on tissot.
1. Choose "encrypt phone" in the settings. -> device reboots
1. Open Settings app again and check that it's not encrypted (you could do the encryption process again)
## What is the current behavior?
Device not encrypted. No warning shown.
## What is the expected correct behavior?
Either encrypt or clearly tell the user that (and why) the process was not successful.
## Relevant logs and/or screenshots
There is an [upstream issue](https://jira.lineageos.org/browse/BUGBASH-2064) and a [workaround](https://forum.xda-developers.com/showpost.php?p=77330471&postcount=3850).
## Possible fixes
change the partitioning (see workaround).https://gitlab.e.foundation/e/backlog/-/issues/548Factory reset do not remove pictures2023-10-20T09:59:56ZVincent BourgmayerFactory reset do not remove pictures# Factory reset do not remove pictures
## Summary
When performing a factory reset, after the reboot, Images were still present
## Steps to reproduce
1- take photos
2- Go into Settings to perform a factory reset.
3- wait for the phone t...# Factory reset do not remove pictures
## Summary
When performing a factory reset, after the reboot, Images were still present
## Steps to reproduce
1- take photos
2- Go into Settings to perform a factory reset.
3- wait for the phone to reboot.
4- Check your gallery.
## What is the current behavior?
After the reboot due to factory reset, if you check you gallery you'll see that your photos are still there.
## What is the expected correct behavior?
All photos should have been removed too.
## Relevant logs and/or screenshots
None.
## Possible fixes
No idea at the moment