[deleted] can you provide a clearer explanation for this request and what it is you wish to achieve by having the options you request.

This would be helpful so that we can either explain sufficiently why the changes might not be implemented either dependent on what it is those functions do/don't do or what issues disabling such features would have across the OS as a whole or get an appreciation of why it should/would be considered.

Thanks dffd, look forward to hearing from you.

    • [deleted]

    MetropleX
    First of all, from my perspective every connection which GOS makes should be accepted by the user.

    Currently GOS gives the option to choose between GOS proxy server or Google.
    GPS and apps which use it for instance OSM works perfectly fine w/o connection to the internet.

    The user should have a power to block any connection.

    Using another approach, every permission which is not obligatory to make the system work properly should have an option to disable it by the user.

    That's why I asked before to block all unnecessary permissions for accessing sensors. They are not all necessary. I assume that Devs have better knowledge to decide which permission is MUST have or NOT obligatory.

    Of course they are many users who don't care so much and even voluntarily install apps which can violate their privacy and security. It's fine. Everyone should have a free choice.

    I would like emphasize that most of us are here (users of GOS) b/o we want to make choices on our own.

      Regards Sensors you are aware that enabling this by default can now be switched off?

      SETTINGS > PRIVACY > ALLOWS SENSORS PERMISSION TO APPS BY DEFAULT

      Regards PSDS I have asked the dev team for what technical reason there is behind the lack of an option being available and will report back with a response when one is forthcoming.

        • [deleted]

        MetropleX Regards Sensors you are aware that enabling this by default can now be switched off?

        SETTINGS > PRIVACY > ALLOWS SENSORS PERMISSION TO APPS BY DEFAULT

        What about system apps?

        MetropleX Regards PSDS I have asked the dev team for what technical reason there is behind the lack of an option being available and will report back with a response when one is forthcoming.

        Thank you.

          a month later
          • [deleted]

          MetropleX Regards PSDS I have asked the dev team for what technical reason there is behind the lack of an option being available and will report back with a response when one is forthcoming.

          Any news?

            [deleted]
            You as a user can go through and disable sensor access for most system apps (besides Settings) but it not recommended and you may experience breakage. If you teat the apps one by one you could compile a list of apps that work without sensors and/or network and post them here for other users if they want to follow your example. Other than that I recommend filing it on the GOS issue tracker.

              • [deleted]

              Lusca
              I blocked sensors for all system apps which allowed to do that.

                [deleted] Please don't bump threads like this without adding any new useful information.

                [deleted] Please read the section on PSDS at https://grapheneos.org/faq#default-connections. The documentation on this has improved since you made this thread. For the Pixel 6 and 7, PSDS is provided by a set of 3 small static files from Broadcom providing information on GNSS satellites and geographical data. Our PSDS cache is little different from Google's PSDS cache, which are both a cache of the 3 small static files from Broadcom. It's simply 3 specific static files that are downloaded. This data is required for normal operation of the GNSS chip and it doesn't work well without it unless you have A-GNSS provided by cellular.

                You seem to be confusing PSDS with the attestation key provisioning proxy. Attestation provisioning inherently relies on using a specific server provided by whoever provisions the attestation keys for the hardware. For every Android devices, attestation key provisioning is done by Google. There's no way to provide a choice beyond either the Google key provisioning server or a proxy to it providing the same interface.

                For both of these services, the services need to be adjusted based on monthly, quarterly and yearly OS updates. These aren't stable interfaces with any guarantee they won't change. There can and will be changes requiring adjusting the server before deploying an OS update using the new interface. GrapheneOS is in a position to update the servers before we release OS updates through the Stable channel. Other people are not in a position to keep up with these non-standard protocol interfaces, and in both these cases there is no user-facing interface informing users of errors.

                It would be possible to add a 3rd mode for disabling both PSDS and attestation key provisioning. Disabling PSDS will greatly hinder the functionality of GNSS, especially with cellular disabled. Disabling key provisioning will break hardware-based attestation on devices requiring it, meaning the Auditor app will broken, as will other apps using attestation. You're welcome to work on this if you want the option to break this functionality. It likely won't be implemented unless a contributor decides to work on it. It's a freely available open source project and your expectations are inappropriate. You aren't a customer. If you want a feature, you should work on it or pay someone to work on it.

                  • [deleted]

                  GrapheneOS If you want a feature, you should work on it or pay someone to work on it.

                  Thank you for clarification.
                  Maybe you should add the disclaimer on the main page. People should know how it works with Graphene OS without curtains.

                  Our main page explains that it's an open source project. It doesn't need to be explained that feeling entitled to directing how developers spend their time isn't appropriate.

                  Based on the response you deleted, you're still misunderstanding what PSDS does. PSDS reduces GNSS power usage by reducing the time needed to get a lock. It fetches static files which can be used for a long time and they substantially reduce how much the GNSS radio has to work. There are a total of 3 static files available and it's the same 3 files for any of the devices using a Broadcom GNSS unit.

                    • [deleted]

                    GrapheneOS Based on the response you deleted, you're still misunderstanding what PSDS does.
                    Are you referring to?

                    I think you  didn't get the point. The user should have a power to decline ALL connections. The phone with GOS without internet works just fine.

                    I understand, only donors can talk about features. I do not feel comfortable with your attitude. I am sorry.

                    From my side this thread is closed/solved.

                      [deleted] GrapheneOS is FOSS and it relies on donations and stuff. Main goal is security and privacy, not adding options that are not only useless but break functionality too. Why would they allocate their limited resources on including this option?

                      [deleted] You greatly misunderstood what was said to you.

                      The project account never said that someone making a donation makes their feature request get worked on. GrapheneOS is an open source project, it doesn't do contract work.

                      When they said "pay someone to work on it", they didn't mean a GrapheneOS developer, but someone independently. Even in that case, whether the patch can then be accpeted into GrapheneOS depends on whether it's something that aligns with the project's goals, if it's wanted and if maintaining it going forward is worth it/viable.

                      Even if someone is able to contribute a feature, there need to be enough maintainers around to port that feature to new versions of the OS in the future.