You are part of the problem. In fact, you are the problem. You know, tenants have rights too, they pay taxes, and as a rule they tend to pay more taxes and get less break for it than homeowners, especially in California, where incumbent homeowners are protected from tax increases.
The property is taxed; the landlord pays the tax directly, the tenants absorb this cost in their rent.
> Careful. You're not a patent attorney (and neither am I). But my attorney told me the engineer to not read claims and certainly not to read them to understand them.
Yes, a standard engineer's employment agreement prohibits engineers from performing patent searches.
Isn't this all a good argument that patents are hindering their intended purpose, e.g., PUBLIC DISCLOSURE OF INVENTIONS to advance the state of the art? If claims are written virtually incomprehensibly and are so useless as to not even be allowed as references to actual practitioners, I would argue they are not serving their purpose of public disclosure to advance the state of the art.
> Yes, a standard engineer's employment agreement prohibits engineers from performing patent searches.
Patent searches are one thing and yeah, big companies like Apple don't want their engineers reading patents at all since it puts them in line for treble damages should they lose an infringement suit. Startups on the other hand, are a different breed and they're not going to fail based on infringement. So you won't see those terms in a startup's employment agreement. Later, maybe.
Also, patent search != reading claims. First, a patent is broken into roughly two halves: specification and claims. Claims are written in a very stylized legal manner which is not meant to teach at all. The specification teaches and supports the claims. Everything that's in the claims must be supported in the specification AND the specification must effectively teach the invention.
So when I say that you shouldn't read claims, I'm saying that you the engineer who's trying to learn from the patent's teaching is wasting your time trying to figure things out from the claims. Figure that out from the specification.
But saying don't read the claims doesn't mean don't do a patent search.
> patents are hindering their intended purpose, e.g., PUBLIC DISCLOSURE OF INVENTIONS to advance the state of the art
This is mistaken. The purpose of patents is to reward the development of new inventions with a temporary monopoly. In exchange for that monopoly, the patent must teach. Public disclosure is not the purpose, it's the other half of the deal. In house lawyers who say never do a patent search are being well, unnecessarily careful.
Much to like, but one point is somewhat outdated and another is missing.
1. The lack of an AppArmor-type MAC implementation is somewhat outdated since Theo rolled his own with "pledge". I'm not a huge fan of how a cabal of Theo plus one or two guys basically hacks out something of new cloth on a whim to solve a problem that's been done many times before, on the arrogant supposition they're doing it better than anyone else has ever done, and then promptly stuck it into production. This has happened many times before. Certainly some results have been good, but case in point, "doas". You upgrade one point release and suddenly sudo is not there any more, you have a new tool lacking basic features with completely different semantics. Yes, you can install sudo as a package if you want. Yes, maybe doas is smaller and easier to audit. But was sudo really a problem? Sure the fanboys will love it, but most normal UNIX people are probably not going to appreciate something like sudo just going away. It lacks little "features" like credential caching, which I am sure the fanboys will tell you is bad to begin with, but which most of the rest of us will find a pain in the ass. This sort of thing happens with OpenBSD semiregularly.
Of course, many of these homegrown solutions are produced after years of Theo & cabal insisting that there was no need for it and it was wrongheaded. There's "pledge," but then there's little things like full-disk encryption, which is basically a requirement for use on mobile, but which OpenBSD never had any use for, until it did, and came out with its own homegrown thing (which still doesn't work that great, especially when upgrading).
*And since so many others have brought up pledge, it's not really a solution on the same scale since you have to build the pledges into the application, there's not an easy system for imposing pledges on an application externally. This makes maintenance and adoption much harder, basically nonexistent for most of the package tree.
2. The big reason OpenBSD is insecure, is its lack of any meaningful update mechanism to their supposedly rock-solid secure base system. Literally the official way to do security updates is to monitor OpenBSD's website, download and apply patches by hand to a source install, rebuild, and run a series of listed commands by hand. If you want to automate this further, you are on your own. It's been this way forever. It's craziness, and it a big reason that OpenBSD is basically not an option for production in many settings.
Upgrading to new releases is a similar deal. The homegrown sysmerge hack has made this slightly less awful, but manual hackery is still required, unreliable, can wipe out customization, and doing a clean reinstall is still urged as the best path in many cases.
How does that matter? Fact is you move from 5.7 to 5.8 and boom, no sudo. Check the release notes, and yeah, it's replaced with Ted's little side project. In 5.9 release notes it's "a little friendlier to use". Not as friendly as sudo, but ok, thanks, I guess?
The upgrading is not really that hard. I'm really at a loss given I find FreeBSD a pain in the butt to upgrade since it always breaks something but have had no problem with OpenBSD other than not reading their man hard link instructions which didn't kill anything but was annoying.
Oh yes, another hand-rolled "coming item," in the world's most secure operating system. Someday, someday OpenBSD will support critical security updates that don't involve recompiling by hand. After all, we finally got "signify" for the base system. That wasn't important at all.
> or you can use mtier.
Right. That's called "on your own." I was going to preemptively predict someone would mention that, but the fact that paid consultants provide a critical feature for security updates as a service that every single serious Linux distro built-in for free is not a point in OpenBSD's favor.
Ahahaha. NO ONE outside the OpenBSD bubble would say that other than as a joke.
And are you not forgetting that many of the critical security patches do in fact involve a series of additional steps that must be performed separately, manually? If you don't actually READ each patch, you can miss a necessary step.
And of course little things like restarting patched services automatically or knowing when a reboot is required, well, that's an exercise to the reader.
> The upgrading is not really that hard. I'm really at a loss given I find FreeBSD a pain in the butt to upgrade since it always breaks something but have had no problem with OpenBSD other than not reading their man hard link instructions which didn't kill anything but was annoying.
I'm not using FreeBSD as a point of comparison here. I love OpenBSD. I also am not going to wave off how crippled it is operationally out of the box and basically unusable for production in many nontrivial real-world settings.
There's also the little issue of getting your head bitten off and shit on for no good reason even when you're only being helpful in the meekest and most good-faith possible manner, but that's only a little worse than par for the open source world.
> but the fact that paid consultants provide a critical feature for security updates as a service that every single serious Linux distro built-in for free is not a point in OpenBSD's favor.
Red Hat's has free updates? I was unaware of that. Mtier is free for the current version.
> Ahahaha. NO ONE outside the OpenBSD bubble would say that other than as a joke.
I have to patch Windows, FreeBSD, OS X (excuse me Mac OS), Red Hat, and Windows for my current job. I really don't get the problem with OpenBSD. I'm no super system admin. You have to read the patch notes with all of them so I thought it was normal. If you don't read the patch notes, you will end up in a world of hurt. Red Hat had some serious issues with the stupid software vendor that requires me to have Red Hat.
I'm not saying OpenBSD is perfect or even great, I just don't think it's that bad when compared to what I have to do with other servers.
Now, if you want bad patches, deal with "enterprise educational software" that requires me to run an 762 megabyte SQL file against an Oracle database then move files to specific locations.
CentOS has. RedHat is simply not free, so paid upgrades are par for the course. Any free distribution out there has free automatic updates - I think even Oracle came around.
> Mtier is free for the current version.
Yeah, for now (didn't use to be the case, might not be the case forever). Regardless, you're now trusting two entities, OpenBSD and MTier, rather than one. This second entity is not officially affiliated with OpenBSD, and they could shut down tomorrow. How do you trust someone like that with your most sensitive OS files?
I keep banging on about this, but it's the single item that prevents me from switching to OpenBSD as my "default deployed OS" for my generic web needs: the MTier situation is shady and undignified for a major project in 2016, let alone one built on security which requires trust; and my time is too valuable to waste it on reading release notes for banal patches and figure out what special-snowflake incantation I need this week. If OpenBSD does not have the capabilities to provide what MTier provides, they should broker an official agreement where MTier becomes the official channel for updates, with OpenBSD guaranteeing some quality control. If nobody wants to risk his reputation on this service, how can I ever trust it?
Yeah, try to use CentOS when a vendor specifies Red Hat (all sorts of hell). So, I pay Red Hat. I did have a vendor that we didn't go with that specified Fedora but not Red Hat. The world is a bit weird, and I have no clue why that would make sense.
I haven't been screwed by MTier, but I would prefer a world where syspatch is done and working. So, I would guess the single item will fall away for you. Just a question of time I guess.
Although, if you don't read the patch notes for a lot of these OSes, you will get bitten in the butt. I got hosed by a combination of Microsoft and Oracle once. If I had read the notes I could have saved myself a weekend of WTF.
How is this to supposed to show "how vulnerable you are to this sort of attack"? This runs standalone.
1. As a general rule, if you download and run an untrusted standalone program, it could probably steal your passwords even if you use a password vault (although that would certainly make it a little bit harder).
2. You can just go into the Chrome password manager and click "show" to see any stored password. No tool needed.
Chrome uses sandboxing and process isolation extensively. Using the default browser password store certainly presents a ripe target if someone manages to totally own the browser, but technically there's not a huge leap from owning the browser to owning an external password store, and certainly not grabbing any and all passwords entered into the browser via a password vault.
I'm not disagreeing that a standalone password vault encrypted with a master password is effectively more secure than the built-in manager. I do think it has been exaggerated both how much more so it is. Saving strong passwords with the built-in password store is generally much less bad than, for instance, using a common memorized password, or using very weak passwords. Both of which are likely outcomes of "never use the password store."
Yeah, this is not an attack itself, just one of the most common post exploitation routes to easy profit. So common that if you have amateur people who try to pirate things, cheat at games or click on the big flashing red banner ad, they're almost certain to come across it and they're almost certain to have common accounts stolen.
Using even a separate password manager, even an integrated one like LastPass raises the bar beyond this extremely basic level and takes it from easy target to medium target, eliminating every common stealer malware I've seen. This definitely doesn't rule out targeted ones of course, like you say, on an objective level there doesn't seem to be much of a difference. At a practical level though based on what's in the wild for non targeted attacks, it's huge.
well, that wasn't as alarming as "one down the shed there that'll use 13 litres of petrol every hundred yards." I hope it is moving a lot of dirt in those 100 yards.
Low end business gear is universally shit. My comcast business router is absolutely awful. I need to get around to putting it in bridge mode and putting a real router behind it. The best thing it could possibly be for me is a coax to ethernet paperweight.
Low end business hardware is just consumer hardware with "business" written on the box and a couple of strings changed on the web interface.
I won't even buy an AP unless it has a DD-WRT/OpenWRT/Tomato image. I've had way too much pain with whatever shit the vendor crapped into the box before they shoved it out the door.
I keep seeing DD-WRT/Tomato/OpenWRT coming up in these discussions; how about an option you could actually deploy to home or business customers and be proud of it.
> The best thing it could possibly be for me is a coax to ethernet paperweight.
This is great! Maybe we can repackage old Wi-Fi routers and sell them as connected IoT paperweights! Makes about as much sense as every other IoT device on the market.
> My home "router" doesn't even have fucking bridge mode.
Maybe you mean your modem? Bridging a router doesn't make much sense... since it's not a router then.
Although I suppose you could have one of those dreaded "combo" modem/router things ISP's peddle these days. There certainly should be a bridge option in that case, and you're rightfully mad if it doesn't!
I mean one of these dreaded combo modem/router thingies, hence the quotes. There is no bridge mode, and I cannot turn off NAT. It's also doubles as a completely fucked up DNS server which I have to override for resolv.conf.
I did this recently at home (saves money after owning it for a year, as it's "paid off" then in monthly modem rental fees), and although I have problems with the level of control my ISP has over the modem (there's no configurations or login, you activate it on their network and they control it fully), it's now just a "dumb modem" and does nothing else.
Then you knowingly bought a combo shitbox. There have always been quality consumer wireless access points, modems, and routers available, but you chose to buy the combo shitbox.
Mikrotiks are an amazing value! Usually they are way over spec'ed for their intended purpose as well, which means you're getting even more bang for your buck.
They have models for home users, businesses, all the way up to ISP "carrier grade" equipment.
They used to be difficult to configure (you needed to know quite a bit about networking and how Mikrotik's do things, since they originally targeted only WISP and more traditional ISP customers), but that's changed significantly in the past few years. They have 1-click setup wizards now, so even people with no networking experience can get up and running quickly, just like your run-of-the-mill Netgear router.
Also, you can run RouterOS (the OS on Mikrotiks/Routerboards) on x86 hardware, so you can build your own router if you have the need.
WebFig, GUI WinBox, and SSH/Telnet feature parity and a config I can export and read as text, fully featured boxes with gigabit for ~$50 USD, need I go on?
Even so, I'd setup my own router/firewall and handle the ISP supplied device as essentially untrusted. It won't be pretty, but its at least tolerable solution until you can work out a better setup.
not saying its the case for you, but it might be interesting to some:
some ISPs don't allow you to enable the bridge mode on the management website of the device. you need to logon to their website with your service account and either open an actual ticket or go through an automated process to "unlock" bridge-mode.
its kinda silly but understandable, as you need to have some understanding of networking for this but most people dont have any at all. and incorrectly configured bridge mode kills any chance of internet for consumers.
The property is taxed; the landlord pays the tax directly, the tenants absorb this cost in their rent.