This kind of thing degrades discussion. Please don't do that here.

The Personal Responsibility and Work Opportunity Reconciliation Act of 1996 (PRWORA)[0]

SEC. 370. DENIAL OF PASSPORTS FOR NONPAYMENT OF CHILD SUPPORT. (a) HHS Certification Procedure.— (1) Secretarial responsibility.—Section 452 (42 U.S.C. 652), as amended by section 345 of this Act, is amended by adding at the end the following new subsection: “(k)(1) If the Secretary receives a certification by a State agency in accordance with the requirements of section 454(31) that an individual owes arrearages of child support in an amount exceeding $5,000, the Secretary shall transmit such certification to the Secretary of State for action (with respect to denial, revocation, or limitation of passports) pursuant to paragraph (2). “(2) The Secretary of State shall, upon certification by the Secretary transmitted under paragraph (1), refuse to issue a passport to such individual, and may revoke, restrict, or limit a passport issued previously to such individual.[1]

The above may have predated the amended copy, as a threshold of $2,500 seemed to be the case at least 3 years ago, for whatever that is worth.

[0] https://en.wikipedia.org/wiki/Personal_Responsibility_and_Wo...

[1] https://www.govinfo.gov/content/pkg/COMPS-1793/uslm/COMPS-17...

But that is a fair concern. While GrapheneOS will continue to support Pixel devices as long as they can, they will not be beholden to Pixel devices once the Motorola partnership is up and running.

They will be beholden to Motorola, instead! But it is a non-exclusive partnership and it sounds like the intention is to move beyond a single OEM. I am hoping that within a few years we see a small number of OEMs all meeting the device requirements GrapheneOS has set, with real consumer choice and more room for the project to maneuver as it sees fit.

In terms of being tied to AOSP, that is a given for the near term. It is still the best option out there and offers the most robust existing ecosystem of apps that has both FOSS options and highly useful closed source options. Major banks are not going to tell Motorola that their customers can't use their banking apps, though I still use 4 or 5 major banking apps on my GrapheneOS devices without issue beyond one bug where it was quickly fixed.

Longer term, an open source hypervisor model sounds like the eventual goal: https://grapheneos.org/faq#roadmap

That will probably happen before modern chipset makers open source their blobs (never?), so I view that as a great compromise that should result in devices that are even more secure, even more private, but still usable by people who live in a society. And it will reduce the dependency on Google significantly as it will give room to non-AOSP apps to run on contemporary hardware with contemporary security.

If nothing else, it will be a major OEM shipping a non-customer-hostile mobile OS officially for the first time in ages, and Motorola's reach is significant: https://www.androidpolice.com/motorola-razr-drives-foldable-...

https://www.congress.gov/bill/113th-congress/senate-bill/716

I do, however, regularly have to check my phone in at [places] and am highly concerned about that.

I'm not interested in bringing about a tech dystopia to combat it, either, but I don't think those are our only two choices.

Threat modeling is important, and selectively false equivalences aren't helping matters, but only add to the theatrics.

Purism's solution, apparently, is hardware switches. As I understand it, the accelerometer isn't disabled via hardware switches unless all hardware switches are disabled, as there is no discrete accelerometer switch: "To trigger Lockdown Mode, just switch all three kill switches off. When in Lockdown Mode, in addition to powering off the cameras, microphone, WiFi, Bluetooth and cellular baseband we also cut power to GNSS, IMU, and ambient light and proximity sensors."[1]

[0] https://phys.org/news/2013-10-accelerometer-tracking-potenti...

[1] https://puri.sm/posts/lockdown-mode-on-the-librem-5-beyond-h...

That's not far off a reasonable criticism of Purism's security model, that a device so wholly compromised it requires one to activate all physical kill switches to disable the hardware in order to so much as safely enter one's device PIN (per Purism's own site content), that it's no longer useful.

Everyone has to make their own trade-offs, but for me that's a model so questionable that its utility value rapidly approaches zero.

Sure, but from the fact that anything can be debated it does not follow that any given debate is nonsensical, which is kind of what you did there.

> ...whatever debate you're referring to is unlikely to be held in good faith.

I don't know which is odder, that assertion, or the notion that two completely different security models can't be debated in good faith because they're effectively identical, because of hand-wavy reasons like, "You have communication protocols on top of IOMMUs as well which are subject to exactly the same security considerations as potential exploits in the USB stack..."

Certainly there's some kind of argument to be made that the Librem 5 is relevant to this post as its adherents see it as a viable alternative to iOS and/or Android-based devices. I disagree, but everyone's willing to make different compromises and that's fair.

I only mention that because a contingent of voices as high in volume as they are few in number endlessly shoehorning the Librem 5 into numerous threads no matter how much of a non-sequitur it takes, has me suddenly paying more attention these days to what's coming from the Purism camp. The more I do the more disingenuous the rhetoric seems.

It may just be a coincidence, but for a project with such a fraught history and tarnished reputation, it doesn't do anything to increase my trust in it.

Those aren't our only two choices, and this is pretty manipulative and fallacious rhetoric on multiple levels. It's difficult to take much of what you say in good faith, given how you persist despite it being pointed out to you repeatedly, and by many people.

Somewhere between your original comment and requiring all advice to have full documentation attached to it is a reasonable course of action. Another quality frequently exhibited by your comments is dealing in absolutes, which tends to undermine your points and make your positions technically fraught.

I think if you're evangelizing an OS people may be unfamiliar with, and for an audience discussing a particular vulnerability, the responsible thing to do is add even the bare minimum of context to your comment rather than continuing your habit of posting fairly bare links sometimes accompanied by terse absolutes as if they constitute substantive commentary. All that serves to do is turn people away from your beloved projects, and frequently backs you into technical corners requiring you to accept even the slightest responsibility for your comments.

Here's a way of doing it: "The bug described in the article still exists within a given VM, but Qubes OS is the most practical solution I've found to split Tor Browser identities across disposable virtual machines, which fully addresses this vulnerability."

I get that you aren't precise with your language, which is usually where people seek to correct you and you double down, but when discussing technical subjects we ought to be precise, lest we inadvertently cause problems for others. And you might, one holds out hope, actually learn that some of your technical assessments are founded on incomplete or incorrect assumptions.

It's easy to be a zealot, and anyone can do that, but it's not actually that much more work to make genuine contributions.

Please don't do that here. https://news.ycombinator.com/newsguidelines.html