GrapheneOS' rewritten Messages app is released
github.com
github.com
> Fairphone has said they don't plan to add a secure element. It can be seen from their current devices that they don't fully keep up with privacy/security backports and lag a year behind on shipping yearly OS releases. They skip over the monthly and quarterly releases entirely. They replaced their own non-GMS Fairphone OS with a dramatically less secure /e/OS option in partnership with Murena. They clearly demonstrate that security and even privacy are not the priorities.
it sounds like they are saying that /e/OS is less secure than fairphone's own OS. with all criticism against /e/OS taken into account, i highly doubt that fairphone would have been able to make their own version of android more secure than /e/OS when they are not even interested in working on that.
so, again, how is /e/OS being behind on updates any worse than fairphone's own OS?
However, calling out on e/OS in the same post, seems to me very counter-productive. We need more OS vendors and less infighting. Calling all custom ROMs insecure and claiming to be the only one is IMHO 'drama'. Particular there are contributions of me microG that are helpful if you want to de-Google ones phone. Graphene has a different approach: fair. People will use GrapheneOS if they share their goals.
Fairphone is about sustainability and a bit about not supporting major tech like Google. I don't think this hurts. In an ideal world we could have both. But sustainability seems to be a non-goal of GrapheneOS.
In some ways /e/ and GOS are trying to achieve different things (/e/ is not hardened and does not claim to be), but /e/ is severely lacking security wise compared to AOSP.
This [0] is, in my opinion, a fair review that mentions many of the issues. That Fairphone is ok with these is telling about their position on privacy and security.
[0] https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-...
No, what it is is true. microG lets you de-Google a phone, but the resulting phone is provably less secure. If stating the truth causes "drama", the problem isn't the person or entity saying the true thing. If that truth shakes people, if it upsets them, they should look into the problem that truth has revealed (not created, as truth isn't something that exists only after someone speaks it) rather than blame those who are speaking it.
Can you provide evidence that GrapheneOS is less secure than LineageOS or other custom ROMs? Because GrapheneOS (and even leaked documentation from commercial adversarial phone hacking tools) provide a hell of a lot of evidence that it is, in fact, considerably more secure than just about every other phone OS in existence.
Because of that, instead of refuting the actual argument being made, discussion always swings towards their tone.
What it is, exactly, that is objectionable? Are there personal attacks being made? Yeah. Towards the GrapheneOS developers. It's something I've seen for myself and if you get into these threads on HN early, you can see how the comment deletions pile up. When they say they are the target of organized disinfo and targeted attacks by malignant third parties, it's pretty easy to believe them. It is in the best interests of many, many very powerful people that GrapheneOS is destroyed.
No one who takes infosec seriously cares about GOS' PR filling their communication with tummy rubs and head pats. Infosec is a nightmare, adversaries are everywhere, all anyone should want to know is whatever is as close to the truth as possible.
I want the open source desktop to succeed, but we can only make progress if we accept that there are a lot of security, UX, and UI issues and start tackling them.
When they say they are the target of organized disinfo and targeted attacks by malignant third parties, it's pretty easy to believe them. It is in the best interests of many, many very powerful people that GrapheneOS is destroyed.
Yeah. There it's clear that there is a lot of organized disinformation, probably by government actors and certainly by other open source and phone vendors that try to sell privacy/eurowashed phones (one Volla astroturfer outed themselves accidentally on Mastodon by sharing information only an employee could know).
Most of their criticisms are valid, but they seem to be absolutely unwilling to make any compromise at all.
Not sure if they want to protect their brand, if any of those criticised issues would increase the work needed by them significantly, or why they are like that.
But I would prefer to have a slightly less secure GrapheneOS on many phones, that helps many many more users than just Pixel owners, over the current all or nothing situation.
Making no compromise to security is the entire point of it's existence.
Forking GOS and porting it to a new device is a huge and unreasonable ask for an individual user. Even less so when you include the fact that you'll need to keep it up to date.
I wonder if fable or astra could wire everything up.
You are dependent on Qualcomm for hardware firmware updates and apparently they charge quite a bit extra if you want continuous monthly security updates [1]. This is possibly one of the reasons that smaller OEMs like Fairphone do not update firmware regularly and instead choose to keep their customers vulnerable to many known CVEs.
> It's not as though we're talking about a device with hardware specs locked behind an NDA and drivers that only support outdated kernel versions.
Fairphone 5 and earlier have an end-of-life Linux kernel. Fairphone 6 is approaching the same fate. None of their devices keep up with the incomplete security backports to older releases, let alone the full security updates via new major releases. All of their devices are missing important hardware security features which should be standard. They're repeatedly said they don't consider any of this a significant issue and have no plans to significantly change it.
I didn't realize fairphone was stuck on an EoL kernel. I guess that means that even if the build can be made to work right now (far from certain given an old kernel) it would likely break in the future.
An OS without the core features and updates of GrapheneOS clearly isn't GrapheneOS. It's not permitted to refer to it as such.
> That's kind of the whole point of FOSS, right?
No, the point of FOSS is that you can take all of our code and use it for other purposes. Calling an incomplete port to another device GrapheneOS is misleading users. It isn't GrapheneOS and must have a unique name.
Honestly while grapheneos is a useful thing that I'm glad exists you're being absolutely insufferable.
Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they're released)
Fairphone's hardware and software is developed by a Chinese ODM (T2Mobile), who even have difficulty pushing out monthly patches very timely. They don't even do QPR2s, major Android updates are very late (usually almost a year), they rarely do driver firmware or kernel updates. There is no way they could fulfill this guarantee unless they started doing software development in-house and paid Qualcomm for monthly firmware updates.
But I agree with the overlap. I use e/OS partly because I can run it on a Fairphone. I'd love to try Graphene.
And why would Meta even do that?
- remind you that the phone is in your pocket, to initiate the infinite scroll
For one, the sales were still perfectly respectable. "Versus the rest of the lineup" is doing a ton of work here, because the rest of the iPhone models sell like crazy. For two, it is still bizarre that manufacturers refuse to make small phones even with that in mind. If you wear very small clothes (or very large clothes) that won't sell as many units, your options are limited, you have to pay more, but you aren't forced to go naked. But there's nobody out there doing the equivalent strategy for phones.
For a small company sure it could be considered a success.
I don’t think tech can be compared to the fashion industry. Also that example doesn’t really work. Because you basically have a locked in group who needs the clothes. Just also culturally there’s reasons why these clothing sizes exist. Nobody needs a small phone.
But across the board it makes no sense for any OEM to make small phones when the data all shows that bigger screens sell more. That’s just absorbing an unnecessary opportunity cost.
I think the only real way small phones will reach the market at this point in time is via a private company that’s basically run as a passion project.
Honestly in this case the consumers do share the blame. They begged for the mini and didn’t show up. If apple couldn’t do it it’s unlikely that the android oems could.
And no, the clothes analogy is not flawed. The point is that in other markets, niche tastes and needs get served even if it isn't as cheap or plentiful. It's only the phone manufacturers which refuse to try to get sales from a smaller (but still quite extant) market.
It's all about scale. Yes 10B is a lot for most companies, but for Apple 5% is just a blip on the radar. They probably also did their market research and found that the vast majority of Mini users would buy another iPhone model if they discontinued the Mini. Those facts combined give Apple little incentive to continue the lineup.
Another thing that further clouds the 5% discussion is that some Mini purchasers may have bought it not because of the size, but because it was $100 cheaper while still getting the same SoC. Maybe those buyers were disappointed by the worse battery life, and Apple could choose to axe it or make it the same price as the regular iPhone and it would drop way below 5%.
...in tech forums where people hold strong opinions about tech and the people who have their pet peeves come out. IRL I have rarely heard somebody wanting Apple to bring the Mini back. Or the stereo jack for that matter.
They were making the SE at the exact same time as the mini, two years in a row, and the mini still got billions in sales. If they want a bigger percent, then do it less often and don't split the demand. It's been four and a half years since they did either mini or SE. People would buy plenty.
> leave money on the table
> opportunity cost
If it cost them that much to have extra models, they wouldn't have five iphone 16 variants that are all just different enough to need five internal layouts. And four 17 variants plus the air.
And this isn't something that would affect their revenue particularly much. So while it's possible I've missed an important factor, even if I'm 100% right it could make sense for most people to say "do the option that leads to more happy customers, while still making boatloads of money", while a CEO says "we have enough happy customers, go for the extra sliver of money". Or an extra payment from Meta or whatever, I wasn't really talking about that idea, I was just arguing against their abandonment of small phones. The point is, don't use CEOs to guide your intuition of what decisions are best.
Like this isn’t a hypothetical, Apple literally released the Mini and it was the worst performing item in their iPhone lineup by far. If it was profitable enough, Cook would’ve kept it.
Like ultimately I don’t necessarily disagree with what you’re trying to say, but like this:
> “do the option that leads to more happy customers, while still making boatloads of money", while a CEO says "we have enough happy customers, go for the extra sliver of money".
The consumers do take some blame here cause they did take the Mini away and people just ended up buying the other more expensive iPhones instead of not buying one at all. Why would Apple do anything different in that case?
The obsession with the Mini is something that is only really popular within an online bubble and isn’t reflective of real life trends, people here are being extremely disconnected from the public with this (and this is coming from someone who wants Apple to add a desktop mode to iOS). The only time Apple seems to maintain lagging product lines are with things like the Air which seemed to essentially be an R&D product for the Duo.
Also do you think people wouldn't buy just about as many iphones if they killed a middle model? That's not by itself a good reason to kill a model or they wouldn't have as many as they do. Like, I'm sure pro and plus each get tons of sales but you could cut one with nobody being upset and redirect that budget to mini.
I really think COVID shutdowns did the mini in. People couldn’t go to the store and try holding a phone where they could use it comfortably one-handed again. And then by the time they could, Apple axed it.
I think people get the wrong estimation about the size of the contingent that want small phones. It is a vocal minority, similar to people ranting every time about headphone jacks. Most people do not care about these things. If they want to hook a wired headphone, they'll get a 10 Euro dongle and most people use Bluetooth. My wife uses a wired headphone for listening audio books at night and I never heard her complain about the stereo jack going away.
Most people take what they're given. Whatever is on the shelf or the front page, that's what they buy. Manufacturers make bigger screens because it's impressive and good for delivering content and provides room for cpu & battery, and most people just go along with it. They think about products the same as the weather. Whatever is, is just what is, like it's just part of the world, not something that people made and people can make differently. If there is choice available, they buy what they were told to want.
Sales numbers are not a strong argument in an environment like that. Countless things sell in huge numbers without anyone actually liking the product or service, even when there isn't a hard monopoly like your cable/internet.
There is a whole other big perverting factor too, which is that for many years now a phone is many people's only computing device. They are preferring phones that are larger that they'd really like for a phone, because they can only have one, and need it to do every job that you and I use a laptop for.
Lack of jack port and microSD card is next.
This is no great conundrum. There is simply a large set overlap. A lot of the people who care about one one, also care about the other.
It's the same as Framework owners and Linux users.
FW is not a linux laptop company. They didn't even barely say the word Linux initially. Their selling point was the repairability and configurability. Only after they had been shipping for a while it became unavoidable that a huge fraction of their users were linux and even freebsd users. Only after some time and only gradually they started providing a little bit of official acknowledgement and support for Linux.
But repair parts and linux os don't have anything to do with each other! zomg why is everyone conflating Framework with a linux laptop company???
https://www.fairphone.com/the-fairphone-gen-6-plus-e-operati...
[1] https://forum.fairphone.com/t/official-lineageos-23-for-the-...
[2] https://wiki.postmarketos.org/wiki/Fairphone_(Gen._6)_(fairp...
Why would that mean it could compete with a Pixel which generally has none of those goals?
Pixels have long term availability of official parts for repairs and also official repairs.
Unlike Fairphones, Pixels have very good updates over the long term. Fairphones do not provide anything close to decent updates and it greatly degrades over the lifetime of the device. Fairphone 5 and earlier have an end-of-life kernel without security support. The devices start out lagging months behind on partial security backports and a year or more behind on full security updates which gets worse over time.
> The more an article would benefit from photos, the less likely it’ll have them.
Which is a bummer because it is a complete different point of view from the more typical user experience
In many cases the repository isn't meant to be more than for source code too, not everyone use their git repository as also the marketing page, that'd go somewhere else.
With that said, grapheneos.org doesn't seem to have any screenshots either, which I also don't understand and think is a bummer. Even though the point of the differences with GrapheneOS might not be mainly visual, just showing what it looks like seem like a no-brainer.
It's like we've had this ancient knowledge passed down for generations but people constantly just ignore it.
Case in point, I recently wrote a CLI to show which of your AWS infra is not captured in terraform, and you can either print the result as a json to consume by a machine or generate a dashboard with some charts. It took me an embarrassing while to realise that I should have included a damned screenshot in the README, in fact I think I only realised when I wanted to show it to my brother.
Also updating them to match every change in the code is a pane. Most app stores have ways to track screen shot assets along with releases, and even GH has a way to add image assets to release notes without tracking the images in Git, but not very many projects realize that's an option.
GrapheneOS users can update to it via the Alpha channel and try it out rather than looking at screenshots. There's still more to improve before it will go to the Beta and Stable channels.
It's the default SMS/MMS app for GrapheneOS and isn't available for use outside GrapheneOS so we aren't trying to promote it as an option.
You mean the perfectly functional (if barebones) AOSP call app? :)
There's only a handful of critical details in a call history, and absolutely no reason for any UI to implement them as secondary or tertiary details: Whether it was in- or outbound. To/from what contact. The date and time.
2 taps for some other extra info such as call length, or further contact details, would be OK I guess, but for first-level info as these, it's 100% bad design.
I mean come on, design-wise this was already a "Done" thing in the golden Nokia days! https://the-gadgeteer.com/2009/03/02/a-week-with-the-nokia-n...
[*] Ctrl+F to find the image below "miss a call".
I might be mistaken but I seem to recall it being a done thing for android prior to several years ago when it was "improved" with an update. Although it's possible I'm confusing the call apps from AOSP and various vendors. Either way several of my past android devices had a significantly better address book, dialer, and call history.
Clearly.
>There's only a handful of critical details in a call history
And they're all there: profile pic, contact name, indicators that show incoming/outgoing + missed/connected, which SIM, a redial button, how long ago (which after about a week shows the date), Tapping the middle expands the row (no obstructive pop-up) to show Block, Message, & Details buttons.
The reason it has 'human times' is because multiple calls with the same contact are grouped, so a precise time doesn't always make sense. Tapping the Details will show all calls in that group, whether it's one or seven, with their full dates, times, durations, and further options. It's never been a difficult UX.
But a precise time does always make sense.
And even if "doesn't always make sense" was true, it doesn't on its own justify a different default.
So what does grouping have to do with it?
I'd argue against relative dates because that's an opinionated design that requires cognitive overhead on the user. A young person might be able to mentally translate, but older ones tend to have it more difficult. Usually, opting for relative dates tells us about the designer's lack of experience with different groups of users than the normative one.
Your comment is unnecessarily inflammatory.
Also, GrapheneOS has very recently released automatic call recording for the Dialer.
I can imagine many reasons to devote resources to it:
* A platform is only as good as its apps. If they want to grow GOS in the general public, it requires a good SMS/MMS messaging app.
* LLM tools greatly reduce development costs, especially for well-known functions like text messaging.
* Without secure messaging (as far as SMS/MMS can be secure), the platform security is greatly reduced.
* GOS got a big donation, or has a volunteer that wants to do messaging ...
But idk what I'm talking about. What is their approach?
If they fix(ed) their messaging app and their keyboard, then they've really eliminated a lot of potential complaints if a less tech-savvy crowd ends up buying future Motorolas.
IIRC when they started first announced their replacement for the AOSP camera they said they hired a developer specifically for it.
Modernizing these apps seems very high-impact. These are the very first things a new user sees and after the initial modernization, they should be relatively cheap to maintain.
Messaging can be replaced with one of the hundreds decent messaging apps.
Unlike the backup app which is utterly unusable, untrustworthy and frankly crap. And CANNOT be replaced by anything else.
As it stands it's impossible to have reliable backups in GOS.
If my phone were lost, stolen or destroyed, I would simply revoke its Wireguard key, buy a new Pixel, flash Graphene, and provision a new Wireguard key. Essentially no data of value would be lost, and restoring my apps and settings manually would take an hour tops. Admittedly, I don't use many apps, so YMMV.
And I'm syncing some of the app data already, but that is not a replacement for the OS apps.
Most of the data cannot be synced like this.
Isn't it because of lack of the root access?
The lack of root is only significant because unlike in other vendors the built-in backup doesn't work reliably, and you can't use third party software.
But I'm very hopeful, recently they released this Messages update, they're working on introducing native RCS somehow (no idea how but I wish them well), and they recently made a first-class automated call recording.
I agree that a new backup system is also high impact, but there can be more than one high-impact thing, and the Message app is really low-hanging fruit.
Personally I don't need RCS so I simply use Textra since forever as it's far better than Messages, but lack of backup is impacting everyone much more - no other app can be used to back up the OS.
They also plan to eventually support RCS in the Messaging app.
That's great. How can a FOSS project afford that? Where does GOS money come from? Did Daniel win the lottery?
They have 14 devs 13 are payed in ETH and 1 in CAD.
Iirc they said something like 2 million in donations in 2025. Vitalik Buterin may have donated at least some time ago.
Proton donates double digits.
Cape has donated around 100k https://www.cape.co/blog/cape-supports-grapheneos and plans to donate 100k this year.
There's estimated 500k users so if 25% donated 10 dollars a year that's 1.25 million.
> Iirc they said something like 2 million in donations in 2025.
That's not enough for 14 devs, plus infrastructure, etc.
> There's estimated 500k users so if 25% donated 10 dollars a year that's 1.25 million.
Unfortunately, 25% would be extraordinary for any project.
They should make their financing public (and maybe they do), being a non-profit and also asking people to trust them with their security. Funding provides influence: if 50% came from adtech or public surveillance companies (e.g., Flock, Palantir, etc.), then people would have questions.
>plus infrastructure
A lot must be sponsored. https://xprivate.lol/GrapheneOS/status/2070298479897833725#m
I expect the official account will give you a reply besides my speculation.
They've stated that all money comes from donations.
Most of what they earn is public as a result of the donation method, like crypto. And most donors are completely anonymous.
GrapheneOS does not accept any funding with strings attached.
What role do you have the project? Or where is their public commitment to that statement?
Though they were stating $10 per year. You only need 2.1% of the users to donate $10 monthly to get to the same amount. I think GrapheneOS is one of those projects that is really important to their users, so I wouldn't be surprised if more than 2% of the users donated monthly.
We're paying around 10 full time developers along with multiple other people. That includes someone in a CFO/COO role and several people who handle community management. Why do you think we wouldn't be able to afford this? We're paying developers around the world rather than hiring people in Silicon Valley. It doesn't cost $250k/year to pay an experienced developer in Eastern Europe.
100% of the funding for GrapheneOS comes from the donations. The vast majority of the donations come from individuals. Cape sells phones with GrapheneOS and is donating $100k/year without any formal sponsorship or deal with them. Donations from individuals are well over $1m/year and will hopefully reach $2m/year soon. We're spending around half of the funding and need to greatly expand our team.
We have a lot more funding available to significantly expand our team are in the process of doing exactly that. We recently hired 3 full time app developers who are working on overhauling our apps. We plan to hire a couple more along with more OS developers. There's also an open role for an experienced QA engineer.
> Why do you think we wouldn't be able to afford this?
Very few FOSS projects receive seven figures in donations, and dependably enough to budget for them. Good for you; you guys do great work.
Security depends on trust, as you know: Very few users can audit GrapheneOS's code for themselves, and of those people, very few have time to do it. People must trust you to use GOS and for the world to benefit from your efforts. Everything you post on HN relies on trust - almost nobody is checking on it.
IMHO trust requires naming funders, for any organization; secretly funded organizations bringing in millions raise lots of questions. If you don't want to name exact amounts, you could follow many non-profits' practice and name them in ~ logarithmic tiers: $1-100, $101-1,000, $1,001-10,000, etc.
> Cape
Cape is part of the Thiel family (or maybe extended family) of companies. That doesn't condemn them; I'm not expressing an opinion; but realistically it's not a confidence-builder for many people (which is too bad because Cape seems like the most secure service provider I've seen).
Good luck!
We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS.
> GOS got a big donation
We receive large donations on an ongoing basis.
> or has a volunteer that wants to do messaging
Everyone doing substantial work on the project is paid to do it full time. We hired all the people doing large amounts of high quality volunteer work. We've moved on to a process of filtering candidates based on their CV, an interview process and small test projects.
So having a bare bones aosp messaging app was never an issue for me. Having said that, I find fossify messages pretty good.
Will try out the new GOS app too.
I don't know anyone under 70 that even has their voicemail set up.
AFAIUI though GOS does intend on providing an RCS impl eventually even if it takes years to do.
I broadly expect third-party RCS apps to drop that though, like how essentially none support all of MMS. did you know MMS supports slideshows (I built support for this once)? 3d objects (mimetype model/gltf+json)? "timed text" (mimetype text/mp4)?
TIL that RCS was designed as a fairly decentralized protocol where every carrier could run their own RCS servers, but it didnt get adoption. So Google stepped in and built their own routing infrastructure, and now mostly all RCS is centralized on Google's servers (even if you use an iPhone, because the RCS server is mandated by your carrier)
This just shows the fragility of the tech and why I wouldn’t want to rely on it for anything crucial.
Do NOT talk about privacy, E2EE, or any of that. To regular people, "privacy" has negative value, so even if they wanted something, your talk of private communication and not being scanned by data brokers and governments will make them want it less.
So what to do then?
I present Signal as a novelty and focus on one single feature: "hey, video calls work much better than WhatsApp! Try it out!"
Bam, instant download.
What I'm saying is if you go, "Try DuskDozerIM, let's message on there! It's private and secure, the government and large ad companies and data brokers can't read your messages and harvest your data" then you evoque a feeling of suspicion (negative value) and their response will be "look, I already have like a thousand apps, I don't really want one more".
One additional way you can confirm this hypothesis is that almost everybody has given WhatsApp access to { all contacts ; all notifications ; all permissions } but if you sell them Signal with the "privacy/security" angle and watch them install it, you will notice they hesitate for a sec and then reply "no" to contacts, notifications and permissions, as if they're suddenly trying to inhabit the conspiracy-theorist-cum-privacy-activist mindset. Which they're uncomfortable with, and don't like. Negative value.
In my experience, Graphene OS doesn't make compromises.
Just because RCS can't be done without metadata doesn't mean it's a fruitless endeavor. Why not have someone use RCS to then get on Signal? That is so much better than plaintext SMS to Signal.
And for most people, RCS between Android <-> iOS is the biggest advancement in encrypted communication for the layman that I've seen since Let's Encrypt.
Google Messages is essentially the only remaining RCS client for Android and it's the only one with end-to-end encryption. It already works on GrapheneOS via a toggle for ICC authentication extending our sandboxed Google Play compatibility layer. We want to add support for it to our own Messaging app but that's not straightforward since it's not at all an open platform even to the extent of SMS/MMS.
Of course it is relevant privacy-wise (Google still gather a lot of metadata about who speaks to who and when), but that's not even the reason I'm mentioning it.
In the RCS specification, there are three lines on a killer-feature: device attestation. A server can whitelist which devices are allowed to connect to it. And of course Google uses this, allowing only Google-certified devices and Apple devices.
And then, there is actually one RCS client for Google's RCS servers. Because Google Messages doesn't use RCS, it uses a custom protocol based on protobuf. My personal guess is that this protobuf is a 1-to-1 matching with actual RCS, and it's both-way compatible. But still, that means that potentially the Google device-attestation won't work with an RCS client.
Sibling comments say that GrapheneOS plan on implementing it. I think it can reasonably work. TBH I'm expecting that giving a LLM the publicly available information about RCS on microG should give a working "send message" within a day (even when using Google apps rather than microG, it's just that the microG work explains the API). And once RCS work in GrapheneOS' message app, it should be pretty straightforward to port to microG, so yay. However I have to admit I'm not optimist about how long it will keep working. I'd say we are two years away from Google enforcing RKP device integrity for RCS, and uh, good luck passing that.
Of course, I'm hoping that, in the EU, the DMA will break this Google/Apple-only device-attestation, but I'm not aware of anyone pushing that ATM.
So now I must have extra dedicated app just for SMS, which could be replaced easily with another alternative messenger if ANYONE bothered to implement simple SMS support, but seems nobody is interesting in this, so I am not interesting in your messengers if you cant be bothered to support at least SMS and use Whatsapp (and have Telegram as backup if WA would block me again, appeal took ~5 hours to resolve).
Unfortunately I think that feature is shutting down.
https://www.verizon.com/support/vtext-vzwpix-shutdown/
I'm still waiting until RCS is supported before I actually use it.
It's not as funny in hindsight, given the unexpected results of that election, but at the time, it felt like top-tier humor.
Right. Installing Google Messages is not "out of the box" just to clear up the sibling comment as they are a stickler for accuracy. It is not installed by default
(sarcasm obvious, but indeed full system backup is sorely missing. Seedvault is crap, not an option)
People prefer larger tap targets on touch screens.
Only in a completely stupid, nonsensically A/B tested notion of "prefer". I'll refer you to this ~~excellent piece of satirical writing~~ actual post from Google design team: https://design.google/library/expressive-material-design-goo...
Are you this … poorly informed
And tons of whitespace doesn't make the tap targets bigger. It exacerbates the problem of bigger targets causing less to fit on the screen.