Profile: 96b171f1...
nostr:npub1rq9x6sk86e8ccw2cm8gsm4dyz9l24t823elespupaxjnzdk026fsca2r93 nostr:npub18kpw3akvdsyk239lx0jgwksr74sq4nlha3r8u9g2rnrhztfpfhysy469c4...they also have no idea what they are talking about.
Privacy by default
GrapheneOS doesn't include or use Google apps and services by default and avoids including any other apps/services not aligned with our privacy and security focus. Google apps and services can be used on GrapheneOS as regular sandboxed apps without any special access or privileges through our sandboxed Google Play feature, but we don't include those apps by default to give users an explicit choice on whether they want to use those apps and which profiles they want to use it in.
We change the default settings to prefer privacy over small conveniences: personalized keyboard suggestions based on gathering input history are disabled by default, sensitive notifications are hidden on the lockscreen by default and passwords are hidden during entry by default.
Some of our changes for attack surface reduction can also improve privacy by default by not exposing unnecessary radios, etc. by default and avoiding the impact of potential privacy bugs with the hardware.
By default, we also use GrapheneOS servers for the following services instead of Google servers:
Connectivity checks
Attestation key provisioning
GNSS almanac downloads (PSDS) for Broadcom and Qualcomm (XTRA)
Secure User Plane Location (SUPL)
Network time
Vanadium (Chromium) component updates
We provide a toggle to switch back to Google's servers for connectivity checks, attestation key provisioning and GNSS almanac downloads along with adding proper support for disabling network time connections. This combines with other toggles to allow making a GrapheneOS device appear to be an AOSP device. This is only particularly important for connectivity checks since the other connections get routed through a VPN which is needed to blend in on a local network in practice.
In addition to our SUPL privacy improvements, we override the SUPL server to our proxy by default. We also add a toggle for users to switch to the standard SUPL server for their carrier (usually supl.google.com) or disable it entirely.
Do not rely on opinions of privacy/security 'experts'
They are here to build their position to monetise it later.
Look.
The same people promote GrapheneOS, Protonmail or Tutanota.
People with basic skills in cybersecurity know that mentioned services are not as secure as they are promoted.
Think about it!
Why do you think that GrapheneOS cares about your privacy?
It's only a marketing and PR gibberish.
For instance.
- GOS is an excellent tool for fingerprinting users. They promote using webinstaller, don't warn people about fingerprinting.
- GOS doesn't have .onion or i2p sites.
- GOS has no option to update apps/system viaTor or I2P.
-GOS forces to use their server if you want to have accurate time on your phone - nowadays it's crucial.
...
Your constant traffic to GOS servers can be monitored.
DivestOS is not ideal but it has more privacy features than GrapheneOS.
When you have no argument you can always play "hostility" or similar card.
You're just a liar. I use to have GrapheneOS on my phone.
Users CANNOT use any other server than GrapheneOS to sync clock using WIFI or LAN.
Why are you lying?
You can read YOUR site.
"An HTTPS connection is made to https://time.grapheneos.org/generate_204 to update the time"
You have no option to choose other server.
Your lies only confirm that GrapheneOS is not reliable.
Tell us about privacy guaranteed by GOS, about forcing people to use GOS servers about encouraging to use Google apps.
You're pathetic. Security/privacy celeb.:))))
DivestOS
What memory allocator is used?
As of 2024/01/09:
jemalloc for 32-bit and 64-bit: all 14.1 and 15.1 devices
jemalloc for 32-bit and hardened_malloc for 64-bit: all 16.0 and 17.1 devices
scudo for 32-bit and hardened_malloc for 64-bit: all 18.1, 19.1, and 20.0 devices
Exception: These devices use jemalloc for 32-bit instead of scudo: akari/akatsuki/aurora/xz2c, cheryl, klte, hlte
GrapheneOS is not a reliable project because unreliable people stand behind it.
Another thing is that GrapheneOS builds a walled garden and forces people to use their servers. You claim that you're security espert. Have you noticed that GOS forces to use their server to sync the clock? Maybe you think that you can have accurate time using manual setting?
GOS is a perfect tool to fingerprint and track journalist and dissidents.
DivestOS allows to make updates over Tor, DivestOS has repository with apps within Tor- .onion address.
DivestOS has .onion address of their site.
Can you provide any details of GOS to confirm claim that GOS is pro privacy and has astonishing approach to the security vs. DivestOS?
Do you have any personal or business relations with GrapheneOS?
try #aves gallery. get the apk on #accrescent for private, secure automatic updates
https://github.com/deckerst/aves
#cybersecgirl #privacytechpro #privacy #security #tools #android #grapheneos
Why do you recommend unstable solution for secure updates?🤔
"When will Accrescent become stable?
There isn't an ETA for Accrescent's stable release, but there is a public roadmap that represents its current stage of development. If you would like to help Accrescent become stable sooner, check out the high priority open issues on the roadmap."
How do you check all signatures of APKs added to Obtanium e.g. APKs from Github?
Try DivestOS.org
GrapheneOS builds a walled garden.
You're forced to use GrapheneOS servers if you want to have a working device.
GrapheneOS doesn't allow you to choose type of Network permission for apps.
..
We've added documentation for the hardware memory tagging implementation in hardened_malloc:
https://github.com/GrapheneOS/hardened_malloc?tab=readme-ov-file#memory-tagging
GrapheneOS on Pixel 8 / Pixel 8 Pro is the first platform using ARM MTE in production. Stock Pixel OS has it as a hidden development option requiring using ADB.
GrapheneOS uses hardened_malloc as the system allocator and enables memory tagging by default. MTE is enabled for all base OS apps and nearly all executables. It's only temporarily disabled for surfaceflinger (due to upstream bug in Android 14 QPR1) and a few vendor executables.
For user installed apps, we enable MTE by default for apps without bundled native libraries and apps marked as compatible. We give users the option to enable MTE for all user installed apps in Settings > Security and users can then toggle it off for specific incompatible apps.
We added a user-facing notification for crashes caused by MTE detecting memory corruption. It makes it easy for users to copy the traceback for reporting the bug to app developers. This also means users don't need to guess when the toggle to disable MTE for an app is relevant.
Our Vanadium browser is also the first browser using MTE in production. In Vanadium, we enable Chromium's PartitionAlloc MTE implementation. PartitionAlloc's implementation isn't nearly as good as hardened_malloc, but we intend to improve PartitionAlloc's security in the future.
Chromium marks itself as compatible with MTE but then disables it as runtime, so other Chromium-based browser have MTE disabled even when the OS has it enabled. We found a bug in Chromium's MTE integration which we had to fix to avoid WebView crashes. It works smoothly for us.
We're also planning on enabling Clang's stack allocation MTE support but it currently breaks Chromium's C++ garbage collection integration along with apps doing in-process unwinding via libunwind. We want MTE for the Linux kernel too, but it integrates it as a debugging feature.
hardened_malloc's MTE implementation is already best in class, but there are some improvements to consider. It currently statically reserves a value for free slots, which reduces the random choices from 15 to 14. It may make sense to use the default 0 tag for free data instead.
MTE obsoletes hardened_malloc's canary and write-after-free check features, so we disable them when it's enabled. However, we haven't figured out an approach to save the memory reserved for canaries yet due to Android supporting dynamically toggling MTE at runtime which is messy.
hardened_malloc uses MTE for all slab allocations, which are all the allocation size classes from 16 bytes through 128k bytes with statically reserved regions for each one. It doesn't need MTE for any metadata since all metadata is in a statically reserved region solely for that.
For allocations beyond the max slab allocation size (128k), there are randomly sized guards placed before/after each allocation along with an address space quarantine on free. MTE would still be valuable for large/arbitrary overflows and use-after-free beyond the quarantine.
We need to investigate the cost of tagging the large allocations above 128k by default.
For non-MTE-capable hardware, we could consider reserving a huge region for allocations above 128k with our own best-fit implementation in userspace to separate them from non-malloc mappings.
Does GrapheneOS allow to choose which type of connection applications can use like in DivestOS?
👇
Network Restriction: DivestOS already lets you restrict network for each app by connection type (cellular/Wi-Fi/VPN), when in the background, and optionally completely revoke NETWORK permission.
#privacy #security #gos