The problem here seems to be that the phone is detected as rooted, not specifically that it's running grapheneOS.
But I agree that it's a big problem. That's how you end up in a situation where google has full control from hardware to final apps like on iphones.
When devs assume that everybody is using the stock android with google services enabled.
It isn't due to the Play Integrity API. That shows a notification on GrapheneOS with a toggle for blocking it to work around it for services not enforcing providing a result. If that was the issue, the original poster would have known from the notification. The issue ended up being PayPal shipping incorrect anti-tampering code incompatible with secure spawning. The original poster figured that out and got it working by disabling the per-app secure spawning toggle.
It's normal to have root (or Administrator) on your devices. After all, they are yours. They don't belong to the device manufacturer. You should have full access to your own devices by default.
Only recently did we somehow normalize the idea that the user should not be the ultimate decider over their own devices.
We've already progressed from "the user should not be" to "the user should never be". Perhaps we will even grow out of calling it "their own devices" eventually. If they can brick it remotely it kinda already isn't really yours?
It does not have a root privilege mode. GrapheneOS doesn't weaken any aspect of the standard security model. It has all of the standard security model and features including hardware-based security intact. It greatly improves security rather than doing that.
User accessible root access is available in userdebug (non-production) builds. There's no system for granting root access to apps. It's no different from the stock OS in this regard, but it's a lot more secure than the stock OS.
I thought the "Private Feedback" field was the demo when I checked the first example which was "Disable a subtree with inert".
The css carousel sound very nice, I wish I could have played with an example directly.
Thanks for sharing.
Wish I didn't have to log in to reddit to read that post. RIP useful reddit links.
edit: looks like I had an extension that was redirecting to old.reddit.com, and it was old reddit that required login. Though when I turned that extension off, I got a "blocked by reddit security" error. ugggh.
Yes and no. DKIM signs part of the envelope to help recipients detect alteration (by verifying authenticity), SPF locks down the permissible origins for the sender. SPF is in itself imperfect and can in some situations be exploited on open-access shared systems. If the two are used in concert they offer decent protection.
Using both has to be done very carefully, because a positive result from the weaker one (SPF) will override a negative result from the stronger one (DKIM). You should maximally use DKIM and minimally use SPF. Ideally, you should not use SPF at all, but there are some senders that still don't support DKIM.
Many email providers and third party security tools default settings automatically bounce or block SPF failures, no matter what DKIM says... so no, not using SPF completely is a bad idea.
Using it minimally is correct, thou. Route outbound mail through as few controlled relays as possible so your SPF record only needs to list infrastructure you actually *own*, rather than growing it every time a new tool needs to send mail.
I have seen way too many clients almost hit the char limit in a TXT record
SPF failures overriding DKIM successes is a direct violation of RFC 7489 section 4.2 [1]. I have never observed such behavior in the wild, though my experience may be more limited than yours. There are two possible explanations anyway, one is that the DMARC record was missing or misconfigured, the other is that the DKIM check did not actually succeed even though you had reason to believe it should have (e.g., misaligned sender domain, invalid/stale/rotated key, etc.).
I would certainly agree that DKIM is harder to get right. However, the TXT record data size limit is surmountable. You can either use EC algorithms, which have much shorter keys, or stick with e.g. RSA and its very long keys, but span them across multiple 255-byte record data chunks. That having been said, I still think DNS providers should do more to make configuring DKIM easier.
Ultimately, if you have SPF and DKIM set up such that both cover all senders, then you are just using SPF. It is the simpler and more forgiving mechanism, so its broad-scoped successes will always swallow DKIM in practice. The only reason I can think of to do this anyway is if you suspect your email provider will change IPs on you and they don't provide their own SPF record, but if that were the case, they are basically telling you not to use SPF in the first place.
EDIT: RFC 7489 was superseded by RFCs 9989-9901 rather recently. Nevertheless, the definition of success, now given in RFC 9989 section 5.3.5 [2], remains the same.
The "logical OR" of DMARC is absolutely a glaring caveat. I run my own MX and would personally under no circumstance omit SPF, because I consider neither SPF nor DKIM complicated enough to warrant consideration.
This is true, and yet DMARC v1 does not require you to use them in concert. Either one (a valid DKIM-signed message with sender alignment or a message that passes SPF checks with sender alignment) is enough to pass DMARC.
Thank you Andrew for sharing your side of the story. We can see that the relationship with Bun and Jarred was far from easy. You say it with your own words and even if it sounds bitter I like it much more than some bland AI assisted content.
Not an expert but I'm pretty sure that constitution > statutes and ordinances > rules and regulations. Meaning that USCIS must follow the intent of the law when publishing regulations. In the case of H1B the law is clear that it gives a specific status of temporary worker distinct to the immigrant status. USCIS itself acknowledges it:
The hierarchy of the law does not preclude USCIS from providing a path to adjust status while in the US. Nothing in the constitution or any statute or ordinance prohibits that.
The H-1B is not "the first step" in a Green Card process. That's why there's an adjustment of status!
You go from non-immigrant to immigrant status and it's not a foregone conclusion. The requirements for the Green Card are entirely different from the H-1B. It's a separate process, with its own rules, fees, timelines.
The "adjustment of status" is simply a way for workers and their families to remain in the US legally while the green card process runs its course, instead of requiring them to uproot their existence (which at that point is often in the 7-10+ year range, if they studied here before the H-1B). Why would we want people to leave and quit their jobs and _then_ give them a green card? They will be in a worse position to contribute to the economy then.
These people pay thousands or millions in taxes and take nothing back. Making their transition to permanent resident smooth is in the interest of every American.
Not like the brazen giant of Greek fame,
With conquering limbs astride from land to land;
Here at our sea-washed, sunset gates shall stand
A mighty woman with a torch, whose flame
Is the imprisoned lightning, and her name
Mother of Exiles. From her beacon-hand
Glows world-wide welcome; her mild eyes command
The air-bridged harbor that twin cities frame.
“Keep, ancient lands, your storied pomp!” cries she
