https://www.openbsd.org/faq/faq4.html#Download

That's something no one can solve for them, never.

But at least they should be capable going into a "Printer-Forum" and ask.

One then will say: Get a refund or roll back the update, i have the same printer...they do that (the asking) with, for example car's all the time.

Absolutely fine with that, plus a massive fine if the refund is not paid back in a fair amount of time ;)

To cover refund is a much bigger "fine" and the money flows directly back to those who suffered, that's not the case with fines, and fines are mostly small change for big-corps.

Just extend the rights of Customers and everything could be fine.

If the customer has no issues there are no issues right?

>Then there are shipping costs, likely the customers bought it from a local retainer, that may or may not be in business...

Again it's an HP and you send it directly to them, the MANUFACTURER has to cover all costs. Your retailer has not made the update so he should have nothing to do with it.

>The endless emails and phone calls.

One email: My printer (serial-number) worked for two years with that toner, since your update it's not working anymore (error blablabla), roll back that update or send me a shipping label.

>Overall the customers are not in any position of power without a forced recall.

Time to change that then right? Restore the functionality of my device or take it back.

You are making a problem where no are.

That's what i mean, a customer is allowed to return a device/car/whatever and get fully refunded if the initial function of a device changes with no technical advantage for the customer.

Fines brings the Customer nothing (aka you don't get your money back) and is mostly small change for the company, no need to change anything...but paying full refunds for let's say a 4yo device, that could hurt allot.

No fines, just allow the customer to send back the devices and get a full refund plus all costs covered by the manufacturer...it could be so easy.

Give back the HP and buy a Brother....that would be called a self regulating Market.

https://en.wikipedia.org/wiki/Linux_Security_Modules

SEBSE is a Framework, MAC is an implementation, those are two different things on different levels.

>MAC framework, but I've never heard of it. What is it called?

It's called MAC...you still don't see the difference?

https://docs.freebsd.org/en/books/handbook/mac/

Look i stop here you have obviously no knowledge of MAC.

>I've been dealing with MAC for 20 years

Yeah no you don't since you don't even know the difference of SELinux and the/a MAC implementation.

That's NOT what i said, the FreeBSD MAC implementation is big and pretty much feature complete, NOT SEBSD.

>The 'different/other/ ways to secure the system are inferior since they offer no protection if root is compromised.

There is no such thing as "inferior" but different approaches, from completely deleting root as a user to using Container/Jail/Zones, Sandbox's, VM's etc. MAC is one of just many methods and OpenBSD voted against it and went another route (and that is totally fine and understandable).

>I don't think MAC is as hard to use as it was

MAC is still very hard, you are talking about SELinux that is just one implementation called FLASK/TE.

Try to implement Brewer-Nash MAC-policy on a Fileserver and i will see you sweating ;)

But as you can see, there is you and me (in this thread) who understand what a MAC even is, and that on HN....that just tells you how many people really have even a understanding what it even is.

If you don't understand a system it's by definition not secure, keep your hands away or start learning your stuff, or at least don't call it secure (the big word that includes many different meanings)

For example FreeBSD has a MAC framework (a massive one btw) and also the "SELinux/SEBSD" framework on top of it (FLASK/TE), but you don't need to use it (not on Linux nor on FBSD).

OpenBSD has no MAC implementation, and with that no framework (SE*) on top of it, but has different/other way's to secure a system.

And TBH i have seen just 3 Customers until now who really develop highly secure/complicated policies (Two use MLS and one uses Brewer-Nash)

I think MAC should be used much more, but it's time intensive and hard to do it right, also to keep the policies clean and understandable need's LOTS of documentation and dedication.

https://www.diva-portal.org/smash/get/diva2:5365/FULLTEXT01.... (2006)

https://hardenedbsd.org/content/easy-feature-comparison

That scam runs actually on YT -> if i where him i would sue the sh* out of Alpha.