mike_wooskey

I host a website that uses mTLS for authentication. I created a client cert and installed it in Firefox on Linux, and when I visit the site for the first time, Firefox asks me to choose my cert and then I'm able to visit the site (and every subsequent visit to the site is successful without having to select the cert each time). This is all good.

But when I install that client cert into GrapheneOS (settings -> encryption & credentials -> install a certificate -> vpn & app user certificate), no browser app seems to recognize that it exists at all. Visiting the website from Vanadium, Fennec, or Mull browsers all return "ERR_BAD_SSL_CLIENT_AUTH_CERT" errors.

Does anyone have experience successfully using an mTLS cert in GrapheneOS?

[SOLVED] Thanks for the solution, @[email protected]

If we consider information to be safe if we encrypt it (e.g., text in a file, encrypted with modern strong encryption), would it be safer (as in harder to crack) if we then encrypted the encrypted file, and encrypted the encrypted^2 file, etc.? Is this what strong encryption already does behind the scenes?

I got a new printer. Auto-discovered, added, and prints fine from Windows in 2 minutes. Auto discovered, added, and prints fine from OSX in 30 seconds. Auto-discovered and added on Linux, but trying to print results in "printer is unreachable at this time" - even after 50 re-installs, different configs, different drivers, different protocols.

I recognized that some computers were on different subnets, but couldn't figure out a pattern. It turns out that the printer has a setting called "Restricted Server List" and the default setting is null. Here's its description in the admin interface: "Comma-delimited list of IP addresses that are allowed to make TCP connections. Example: 157.184.0.0/24. where 0 is a wildcard and /24 is the network prefix."

It also has a setting called "Restricted Server List Options", set to block all ports by default. Here's its description: "By default, addresses not in the restricted server list will have all access blocked. When Block Printing Only is selected, addresses not in the restricted sever list will be blocked from printing only. When Block Printing and HTTP Only is selected, addresses not in the restricted server list will be blocked from printing and HTTP. "

Admin interface doesn't say this anywhere, but the default setting of no restricted servers apparently allows access from other networks, but not from the same network as the printer. I set the restricted servers to "192.168.132.0/24" and then I could access the printer admin web page and print to the printer from my Linux box, but not from any of the computers that were working before. So I set it to "192.168.0.0/16" and every computer on all subnets in my house can print and access the printer admin.

The default setting of no restricted servers was extremely non-intuitive in that it actually only restricted servers on the same subnet. And there was no such documentation.

What a crappy waste of 7 frickin' hours!

I'm creating a Durable Power of Attorney, and I can choose whether to grant my Agent the power to deal with my taxes. My question is: does granting the Agent this power also make them responsible for my taxes? E.g., if I owed the IRS $100,000, would my Agent suddenly be responsible for paying the IRS $100,000 if I didn't have enough funds? Or if they made a decision that got me in trouble, would they be in trouble?

I don't expect legal advice, but I'd like to ask you not to share your opinion. I'm looking for something in between: anecdotes of your experiences.

Thanks for sharing!

FYI, here's the phrasing I'm currently planning to use, though this isn't set in stone:

In regards to taxes, the Principal authorizes the Agent to:

Prepare, sign, and file federal, state, local, and foreign income, gift, payroll, property, Federal Insurance Contributions Act, and other tax returns, claims for refunds, requests for extension of time, petitions regarding tax matters, and any other tax-related documents, including receipts, offers, waivers, consents, including consents and agreements under Internal Revenue Code Section 2032A, 26 U.S.C. Section 2032A, as amended, closing agreements, and any power of attorney required by the Internal Revenue Service or other taxing authority with respect to a tax year upon which the statute of limitations has not run and the following 25 tax years;

Pay taxes due, collect refunds, post bonds, receive confidential information, and contest deficiencies determined by the Internal Revenue Service or other taxing authority;

Exercise any election available to the Principal under federal, state, local, or foreign tax law; and

Act for the Principal in all tax matters for all periods before the Internal Revenue Service, or other taxing authority.

I understand that if you have Bitwarden (or any password manager or browser) configured to autofill your password when it encounters a "password" field on a web form, an easy exploit is for the web form to have hidden form fields (e.g., address, phone, email, ssn) and your autofill app will fill in your info into those fields, even though you only wanted it to autofill the login.

But when you have autofill turned off and you click in a form's "login" field and select a login from Bitwrden's contextual menu, Bitwarden automatically also fills in the "Password" field. Does this mean that the exploit exists even if autofill is turned off, as long as you're using any form of an "auto-fill" function?