That requires access to the actual phone and the unlock code in the case of WhatsApp (you need to identify to add a WhatsApp web client).
For telegram it's a bit easier yes, but the user can set up an additional password. I have done so of course. Note that telegram is not E2EE so they can give your stuff to the police at any time unlike WhatsApp and signal.
For signal I don't know as I don't really use it but i understand it works the same way as WhatsApp, scan a QR code and authenticate to the phone.
Also, with all 3 systems it's clearly visible when you look at the linked systems.
It is possible to intercept text messages and phone calls in such a way that the recipient never even knows a text message or phone call was sent to them in the first place. SMS is an extremely insecure channel for handling authentication codes.
Yes I know but when you want to link a WhatsApp Web client to a phone with WhatsApp, SMS is not used. You need to scan a QR with the phone in question and sign in to the phone.
SMS is used to register WhatsApp to a new phone, but that signs the original phone out. Also, you need the pin code that WhatsApp forces you to set. If you don't have it you have to wait a week if you got a recycled number. Also the original account holder is notified you tried it.
So this method cannot be used by the police to snoop unnoticed. I believe signal works the same as WhatsApp here, it also forces you to set a pin now.
For telegram this can be used yes but you can set an optional extra password. And also like I said telegram is not E2EE anyway so it's open to warrants.
Apps are written for android. Graphene can run all the apps because it's android. If it couldn't run apps, you wouldn't use it. Are you posting today from a pinephone?
Their post history has several posts related to PostmarketOS on the Fairphone, so kind of, possibly? pmOS does have Waydroid to run Android apps, though, which also relies on AOSP.
Waydroid can't run nearly as many Android apps as AOSP on bare metal or especially GrapheneOS with the compatibility features it provides. It's an approach with far more limited compatibility.
Waydroid has very poor privacy and security due to disabling most of the app sandbox. It's also based on an old version of LineageOS so it's missing many important privacy/security updates, but it's much more relevant that it doesn't have SELinux and exposes much more kernel attack surface to apps. SELinux is not an extra layer of security for Android but rather is used in a far more deeply integrated way than any typical desktop/server usage. It's a huge portion of the security model including the app sandbox and protecting the Linux kernel.
We greatly prefer virtual machines over a half-baked container approach disabling most of the privacy/security model. There's already hardware accelerated virtualization on all of the supported devices for GrapheneOS and we plan to make a lot more use of that in the future.
What's the concern? They are working with Motorola as a manufacturer. It'll probably be a hard fork eventually but why not make it work in the meantime.
If they hard fork, a lot of apps that are generally "necessary for the average person" (e.g. Uber, banking apps, Gmail, Whatsapp/Wechat/Line) might stop working.
I mean we privacy nerds all love webapps but the reality is the people actually in charge of S&P500 companies hate them. They really, REALLY want to fingerprint your device and use it as a verification and tracking mechanism.
Until that changes, webapps aren't going to sell.
Even Google tried multiple things to "sell" the idea of webapps (e.g. Polymer project) in 2011-2015 and failed.
Funny enough, Wechat kinda succeeded at webapps in China because there's a strong user preference to stay inside one monolithic "everything app".
I find, as a user primarily of free and open source software, it’s really the opposite: native FOSS apps have minimal tracking and analytics that defaults to off or is easily disabled, while most free and open source webapps are behind Cloudflare, blocking access to them until I turn off my VPN and disable the anti‐fingerprinting features in my browser.
I don't want to see more groundwork for web apps. GrapheneOS is meant to be secure, which means running trusted apps on-device. My messages are less secure if they permanently are stored on a server.
Yes, but there is no alternative other than giving up. Starting a new OS from scratch with zero apps is a much worse starting point compared to a platform where 99.9% of apps work (minus those relying on Play Integrity with strong integrity) which may have its rug pulled in the future. The race here is about getting to a big enough market share that GrapheneOS cannot just be ignored as completely niche but has to be treated as a small but not insignificant minority.
It's not ideal, but in the case a hard fork happens, they could implement the same APIs and most apps will probably continue to work. Similar to how microG is a replacement for Play Services and still works for most apps (not as well as sandboxed Google Play of course).
Above that, not much would change for a few years anyway, because apps still target ancient Android versions.
Seriously, I don't see a mediocre android provider like Motorola running and maintaining a hard fork.
Forking is all easy, keeping it up to date year after year as codebases diverge is a whole different story.
I could see Samsung doing it. But they won't, they're too good buddies with Google. But they have the resources. A Motorola no. The grapheneos team won't either, maintaining a disparate fork and introducing new features independently from aosp would just be beyond their scope. You're not just hardening at that point. You're basically doing everything.
Don't forget when Huawei didn't fork. Well they started with that but then replaced every component with their own design. It's easier because if you fork you're still bound by decisions made by the original party. Better to greenfield the whole thing then.
And look at how many people made a soft fork of chrome with some ui changes. There's tons of those. There's no hard fork that no longer follows Google. Even a large company like Microsoft didn't.
They could for a while but what's the point if it's not sustainable? Google is not going to turn around and make it more open again.
With every Android release you will build up more feature base to replicate. Unless you cut all ties and drive a separate ecosystem but good luck getting enough developers to buy into that.
They basically have opposite goals to Google so I don't imagine there will every be good feelings there. There shouldn't be.
Yes Google wants android to be secure, but the problem is that to be truly secure it should be secure from Google too. And they don't want that. They want it to be their personal datamine and walled garden. Just like Apple with ios.
Google staff might follow you but their actions speak otherwise. Closing off AOSP, convincing OEMs to lock their bootloaders. They really want to consolidate control over Android.
Google is the one making bad actions, which it makes sense to complain about. They moved to building in private so forks don't get features as they come and more recently they stopped providing certain source code in a timely manner.
We've collaborated with many Google engineers working on Android. Many of their engineers, security researchers and even people in management positions follow us on social media. One person who describes themselves as an AOSP engineer on Hacker News doesn't reflect what their overall engineering team thinks about GrapheneOS. This person likely also finds the security engineers at Google complaining about the same things and pushing for improvements annoying too.
So what should they do instead? Just give up? Assume that it's simply inevitable that Google will cancel AOSP entirely and so Graphene should hurry up and die?
Apple isn't going to let them build on top of iOS, and anything except those two is dead in the water because it'll never have users because it is missing a bunch of critical apps, and will never have those apps because it doesn't have users.
IE's monopoly was replaced by Chrome and Safari's, and Safari only exists because Apple gives you no choice but to use it on iOS. Firefox had a brief spot on top, but it really didn't last that long.
Windows still has the vast majority share of desktop.
Chrome is the outlier there. It didn't come with any desktop OS and still got near 100% market share, even before Android contributed to that. How? It's worth studying.
Yes but that's my point. Monopolies don't last. We have other ones now yes. But that's because the earlier ones died.
And yes we still have windows as the major desktop OS but don't forget, in the 90s/early 2000s windows was equivalent to computing.
These days the desktop OS is much less relevant than it was and many people don't even own a laptop or desktop anymore. They just do everything on their phone. And Microsoft totally and completely lost that race.
Android is an open source Linux distribution for smartphones. It doesn't have to be used with Google Mobile Services. AOSP is far more private, secure, usable and compatible with a far broader amount of apps. Why wouldn't we use that as the starting point even if the goal was to diverge?
The AOSP does not run modern Android apps, since Google has been replacing the APIs those apps require with closed source versions (that only ship as part of Google Play) for over a decade.
No, that's a widespread misconception. Google Play services is nearly entirely APIs for using Google services. It hasn't replaced AOSP functionality and the AOSP APIs are still there. If you want to avoid Google services then there isn't much that's useful in Play services. Getting developers to not depend as much on Google services such as supporting UnifiedPush in addition to Firebase Cloud Messaging leads to those apps no longer requiring Play services for that functionality.
That is not true. AOSP can run all modern android apps, and google play APIs are provided as alternatives, but not replacements, for AOSP functionality.
That's a huge downgrade for privacy, security, usability, battery life and compatibility with apps. GrapheneOS is Linux too. Linux doesn't mean glibc and systemd. Linux is unfortunately not a great base for an OS focused on privacy and security but it's the only practical choice at this time. In the long term, it needs to be replaced as the bare metal kernel.
Testing the FLX1S for a few weeks as a media player, modern day iPod tool with offline content storage / temp caching. Battery is better than current Android phone. Both have areas of better usability.
I would recommend it as tool for a Linux app designer to use with testing and user improvement. Helps find issue not present on a laptop or desktop. Highlights the difference in solution choices; Python vs Node.js vs Rust.
I'm getting away from Google as far and fast as possible. The sooner the bandaid is pulled the better and more freeing. Google's path with being able to reject those that they don't seem worthy to run on Android, that is a prison.
Personally, I should have root access to the device so that all content which must be archived can be or consumed with another tool; Category Theory. I should have direct access to copying or backing up SMS with ease. Watching the network traffic to know what is actually going through.
Security is also being able for one to learn about the actual operations and test and validate them.
So say you use a USB device to host the kernel boot image which then requires manual password authentication to decrypt physical device drives. Without the USB device, it boots into duress mode.
Duress mode provides a false shell into a working phone. Physical security system do this, by provide false statements of what is going on. Wipe the real stuff in the background if need be.
GraphneOS is using a Linux Kernel. I'm looking for something more Linux Distro style of implementation. Not choosing GraphneOS is pure objective to remove myself from Google and Apple as much as possible in a communication tool.
Android device has become phone and text only. Linux device has become my engagement. Going for a walk without primary communication is peaceful.
This, 100%. It's exactly why I would choose a standard Linux distro any day over GrapheneOS. Biggest reasons for me being:
- No dependency on Google
- Actually free and open OS (this means: root access to device, being able to customise any part of the distro/WM/DE, full, low-level access to external devices etc)
That is a lack of imagination of what a _working phone_ as a false shell really is.
Not to want to give too much. Cell phone companies have no issue deactivating an account with a stated text message. Duress kernel can mimic it with other slight of hand displays that the _foot_ will accept as reality.
User lock down versus machine lock down moves to allowing the machine holes to be used for bypassing. User lock down allows for analyzing and patching the machine holes.
I have it. It's far too slow to be useful, and it's not the hardware's fault. GTK and Libhybris are bad separately and hot garbage together. This problem won't be going away while the hardware is relevant.
Yes RCS is a pig with lipstick. Invented by the carriers to recoup some control over instant messaging, then abandoned and picked up by Google for the same reason. They're the ones that added encryption to it.
It was always meant to be a walled garden. Exactly what an open system shouldn't be.
RCS is important because it provides end-to-end encryption (E2EE) for contacts with Google Messages and iOS. That means having E2EE for the vast majority of smartphone users since Google Messages is the standard GMS Android carrier-based messaging app.
It's important for us to provide out-of-the-box end-to-end encrypted (E2EE) messaging for contacts on Google Messages and iOS. Both Google Messages and iOS provide RCS with end-to-end encryption via Messaging Layer Security (MLS). Google Messages is the standard text messaging app on Google Mobile Services Android and iOS now also supports RCS with MLS. The vast majority of people have an E2EE messaging app on their smartphone and it's important for us to provide compatibility with it. Currently, a growing number of our users are installing Google Messages to have better usability and privacy for texting with contacts on Google Messages and iOS.
People can already install the messaging apps of their choice on GrapheneOS. It would go against our approach to choose specific messaging apps and protocols to bundle with the OS beyond SMS/MMS/RCS. We shouldn't be the ones choosing Signal vs. SimpleX vs. Element or other options but rather that's up to users to decide. We need a messaging app to handle carrier-based messaging in the OS including providing end-to-end encryption for it and the rest is up to other open source developers.
It would go against our approach to choose specific messaging apps and protocols to bundle with the OS beyond SMS/MMS/RCS. We shouldn't be the ones choosing Signal vs. SimpleX vs. Element or other options but rather that's up to users to decide.
I disagree with this somewhat. Apple and Google make these sweeping decisions for their users and in effect promote one tech over another. Adopting RCS and integrating it natively, but shunning open protocols and leaving them for third party apps (with probably worse OS integration) means you are following, not leading.
I would at least consider shifting approaches somewhere down the line. Yes, there are a plethora of open messaging protocols out there, but adopting one for first party integration doesn't prevent the others from being used.
RCS is a modern replacement for SMS/MMS with end-to-end encryption (E2EE) support via MLS. We have SMS/MMS so we need RCS to replace those. Similarly, carrier-based calls are there and should get replaced with a newer standard with E2EE.
RCS is what GMS Android and iOS provide so that's what people need to talk to non-GrapheneOS users.
Which non-carrier-based messaging app or protocol do you think we should include and why? What happens if we decide that's no longer the best one wand want to get rid of it? Apps included in the OS cannot be easily removed but rather only disabled by default for new installs and phased out for new devices. Otherwise, users would have their working setup break.
Yes I understand your point re: interoperability, and I think you've made a convincing case for RCS.
I think in the short term, you should take a look at e.g. Cheogram, Conversations, and Element and consider ways to enhance integration. Address book integration, automatically extending contact do not disturb exceptions, and maybe even dialer integration.
In the long term, it would be best to try to guage antitrust regulator attitudes wrt to protocols like XMPP and Matrix. In the end, they are the only ones who can really force mass adoption of an open protocol. But alternative OSs having native support and integration for such messaging protocols can tip the scales and be used as evidence of the protocol's viability and legitimacy.
I agree. The OS maker has a ton of power with the default apps and putting SMS and phone calls as the default communication platform of the OS is contrary to the goals of giving people more privacy.
And the OS should come with a GrapheneOS Monero wallet to compete with Google Wallet/Apple Pay.
> And the OS should come with a GrapheneOS Monero wallet to compete with Google Wallet/Apple Pay.
This makes no sense especially when you’re comparing it against Apple Pay and Google Wallet. They shouldn’t waste resources on something so pointless. The only exception is if they can actually make an NFC capable app that can handle cards.
Unless one wants interoperability with other people who use Apple and "Samsung" (because they don't know the word Android refers to an OS). It's a de facto standard now, whether you like it or not.
Seems neat. Do you write your own connectors or have you found ones written by others? It looks like first party is very limited and I didn't see a link to any community listing.
I mean, Raymond Chen has been writing The Old New Thing consistently for over 20 years. Nearly every single entry is interesting, informative, and illuminating, aimed at every facet of software engineering, old and new, over the decades. He may be part of the final bastion of quality and care for detail at MS, dwindling and faint as it is.
Windows doesn't need or deserve defending. It's atrocious. But this is a silly comment.
Well Google is becoming worse every year, but AOSP is way ahead of Linux on Mobile, for many reasons.
The thing is, AOSP is open source. Just like Linux is not controlled by one of the TooBigTechs, I could imagine a fork of AOSP becoming a viable alternative without depending on Google anymore.
And supporting alternative Android OSes (like GrapheneOS and LineageOS) is one way to support that vision.
Linux on Mobile is nice, but unfortunately I think it's an uphill battle because of all the proprietary firmwares?
One obstacle to making AOSP independent is the included apps. Last I knew they were overly basic and somewhat derelict because Google has long been favoring their own closed source counterparts, and third party manufacturers all ship their own (often kinda garbage) alternatives.
Not insurmountable at all, building decent apps isn’t rocket science, but a substantial investment of time and energy nonetheless.
> but unfortunately I think it's an uphill battle because of all the proprietary firmwares?
In my GNU/Linux phone, all drivers are FLOSS and all pieces of firmware are backed into the replaceable peripherals (modem M.2 card and WiFi M.2 card).
I feel like supporting Android alternatives is also fighting for my rights. Isn't it?
And again, I'm really impressed by all the work done by the Linux on Mobile projects. I'm just saying it's an uphill battle, and it's nowhere close to any AOSP-based system.
reply