Hulk

  • Feb 7, 2024
  • Joined Jun 10, 2022
  • In My Research Thesis on the Privacy of GrapheneOS vs. Stock Android

    Hello community,

    over the past 3 months I wrote my bachelor thesis, comparing the privacy aspects of GrapheneOS (with and without Sandbox) vs. a normal stock android on a Google Pixel 6a. It mainly focused on network traffic (how much, domains requested, domain reputation, geographical spread etc.). I thought this may be interesting for you so I decided to share it here with you today.

    https://drive.google.com/file/d/1AIQgxAUhvFjW68pF6thQSPcWHoUkza6l/view?usp=sharing
    (Spoiler alert: GrOS is less privacy invasive ;))

    Feel free to ask any questions you may have.

    Greetings
    Martin

  • In Anyone impacted by Android 14 user-profile data loss bug?

    The fact that GrapheneOS regularly corrects bugs before they were even found on stock android is so insane. This project is godsend fr

  • In Recommened way of migrating from stock android to grapheneOS?

    To be clear re: Seedvault, Seedvault only allows restoring from Seedvault backups, so you'd need to be going from one OS that uses Seedvault to another for it to work.

    GrapheneOS still uses Seedvault, but the project realizes that it has a lot of shortcomings so the approach that it will take in the future is completely replacing it with something built in-house that will support a lot more than Seedvault does and be much more reliable.

    I know you won't like this answer, but my suggestion would be to do move everything over manually.

    • In Apps knowing SIM/Network country code / Apps sharing accounts between themselves

      For your first question, you likely weren't using airplane mode, so the app was able to determine the country code based on the surrounding cell towers and/or the SIM card in your phone, using the country code burnt in it. There's nothing unusual about this, and it's all documented on the GrapheneOS website.

      For your second question, the Amazon app you had in the same profile provided this to the Prime app, as the other user above said, apps can mutually agree to pass data back and forth. This is expected. If you don't want apps to be able to communicate with mutual consent, put them in different user profiles.

      For your first concern, there's already a filed feature request on the issue tracker:

      https://github.com/GrapheneOS/os-issue-tracker/issues/502

      For restricting app communication within the same profile, the project has been working on a feature that does this in a comprehensive manner, which will take a lot of work so that it's not leaky. Again, for now, using user profiles to isolate apps from one another is the correct approach. Details on this potentially upcoming feature here:

      https://twitter.com/GrapheneOS/status/1636042398043086850

      Now, if I may: it's perfectly fine to have questions and concerns. After all, you're using GrapheneOS because you care about security and privacy. But your wording makes it sound like what you experienced is outside of the norm, not documented or unknown, which is not the case. I would like to ask you to please frame questions like this as what they are... questions, and to not make claims that GrapheneOS is somehow not secure or private just because you experienced something you did not understand.

      I will also take the liberty to change the title of this thread to better describe your actual questions instead of the current title, which is sensational at best. Thank you for your understanding.

    • In Play Store Auto-Update not working

      Giklunewas According to this Google support page, the following constraints need to be met in order for Play Store to automatically update apps:

      • The device is connected to a Wi-Fi network.
      • The device is charging.
      • The device is idle (not actively used).
      • The app to be updated is not running in the foreground.

      It might be that the aforementioned conditions are never properly met in your case. For example, if you're only ever charging your phone during the night and never keep it connected to Wi-Fi during that time, I assume that would be a reason Play Store doesn't automatically update your apps.

      Aside from this, I don't really see what could be causing this issue.

      Edit: I realize the link I posted seems to refer to automatic updates in corporate environments specifically ('Managed Google Play'). Not sure if it applies for Play Store in general.

        • In What does the SUPL do?
        • In GrapheneOS Apps (app repository client) version 16 released
        • In A couple of app notifications don't work
        • In Close notifications on lockscreen?

          JayJay [deleted]

          I was curious about this so I tried to figure it out. I'll skip all the boring stuff to just say it looks like since the phone is locked and notification are marked "sensitive", they cannot be cleared.

          The comment above this method explains why this happens:

          /**
 * @return Can the underlying notification be cleared? This can be different from whether the
 *         notification can be dismissed in case notifications are sensitive on the lockscreen.
 */

          To test, you can dismiss notifications if you show notification content on the lockscreen here: Settings > Privacy > Notifications on lock screen.

          btw, all this appears to be AOSP stuff, not GrapheneOS stuff. I did most of the code searching on https://cs.android.com. After finding related stuff there, I checked GrapheneOS's Github and nothing was modified from AOSP. Also, protecting notifications isn't listed as a GrapheneOS feature.

            • In LINE writes in DCIM despite permission settings

              boarim

              This is okay. Modern apps that target recent enough api levels can do this.

              I'd suggest you read through this part of the GrapheneOS website: https://grapheneos.org/usage#storage-access

              A relevant part:

              For modern apps, access to the shared storage is controlled in the following way:
     - Without any storage permission, an app is allowed to:
          - create media files in standard directories (audio in Music/, Ringtones/, etc, images in Pictures/ and DCIM/, videos in DCIM/ and Movies/)
          - create files of any type (both media and non-media) in Documents/ and Download/
          - create new directories inside standard directories
          - rename/delete files that were created by the app itself
          - rename/delete directories if it can rename/delete all files within those directories

              There's a lot more info there, so I'd still suggest looking at that section of the website.

                • In Adapter to charge and audio out at the same time?
                • In Sensor Automatic Turn off (important)

                  Sounds like you want a feature like the Bluetooth and WiFi timeout but extended for Camera and Microphone access.

                  The recommended way of doing this is instead to just grant the app one-time access to the Camera or Microphone.

                  https://github.com/GrapheneOS/os-issue-tracker/issues/1718

                  We recommend granting one-time access for user installed apps instead of ever granting allow while in use access to them. It's handled nicely by the permission system itself without needing the toggles. We don't currently plan on adding automatic disabling for camera/microphone/location since that handles it well and apps could keep these active by accessing them repeatedly so timeout wouldn't really work as intended. It could be bypassed any time it was ever actually particularly needed. Consider installing an app that runs a foreground service and continues using camera/microphone after you grant access. As long as it accesses frequently enough, it will never time out.

                  • In PDF reader and "Semsors"?

                    LefoDpct

                    The sensors permission includes

                    an accelerometer, gyroscope, compass, barometer, thermometer and any other sensors present on a given device.

                    https://grapheneos.org/features#sensors-permission-toggle

                    The permission is enabled by default for all apps because it can break compatibility.

                    I haven't found a need to have the sensors permission for the PDF reader. You can safely disable it if you like.

                    The only user app I enable the sensor permission for is the Camera app so that the app can get gyroscope data and tell whether I am taking a photo in portrait or landscape mode.

                    It's not recommended to disable the sensors permission for any system apps.

                    • In Hulu App

                      • [deleted]

                      • Post #3

                      Hulk

                      Oh wow, just realized Netflix is the same.
                      That's really annoying of them.

                      Thanks for info

                      • In Uninstalled Packages in Apps Origin and Use

                        Got it. Thank you for the explanation and links.

                      • In Play Services update
                      • In Uninstalled Packages in Apps Origin and Use

                        snowball

                        It sounds like what you're seeing is the "Apps" app (brief info on the website here: https://grapheneos.org/features#grapheneos-app-repository). It's basically an app store for GrapheneOS. The Apps app will update some GrapheneOS apps when updates are available. You can also use the Apps app to install Google Play and its dependencies if you'd like.

                        For more info about Google Play on GrapheneOS you can read through a few sections of the website starting here: https://grapheneos.org/usage#sandboxed-google-play

                        • In Graphene keyboard settings?
                        • In Sandboxed Google Play for push notifications breaks privacy?
                        • In Channel Diversity Overload