Also, the studio paid a professional to peep at all the inter-frame pixels and turn the knobs right when they encoded the bluray. I might be able to get a perceptually lossless rip that's 25-50% smaller than the original, but it's just not worth my time.
I don't because that would be impossible. Every business has different rules. But if you (as a business) want to to use this, you will find a way to make the changes to those "middleboxes". It's not your network, it's your business's network.
Large multi-national corporations, by way of their sheer size, tend to force their vendors to bend towards their needs, not to adapt to meet their vendors' unusual networking requirements.
Of all the SSH servers in the world, what percentage are listening on a port other than 22? To answer this question, you can visit https://data-status.shodan.io/ports.html and see for yourself.
By "unusual," I literally mean "not usual/not typical." Not "never happens."
I'll explain it once again, then leave this thread:
Companies frequently put egress network policies in place that confine certain protocols like SSH and HTTP to certain ports. They do this in order to achieve compliance with regulations, to achieve security or operational certifications, or simply because they're paranoid. It's not necessarily the least restrictive means of accomplishing their goals, but that's what they do. And if they're big enough, they're going to use the size of the deal and their brand equity to persuade their vendors, who might ordinarily prefer to offer a service on a nonstandard port, to provide it on the customer's preferred port instead.
If you still don't understand, I'm sorry, but I cannot assist further.
Companies might do that. They have the right to do so. If they still want to use that service, they will find a way to use it. Be it by vendor-coercing or simpler methods.
Just because those companies exist, does not mean that their shitty practices have any imapct on real internet connections. If you as a paying ISP customer want to use a custom port or whatever, it is going to work. So you as a developer don't have any restriction (which you don't know anyway beforehand) if you are developing a solution for a problem.
"Middleboxes" is a hackernews meme that is thrown around because people here work at places who restrict stuff and they can't bother to change that situation but instead complain about it.
The fact that games exist and they use all kind of ports is proof that this is not a problem for normal networks.
I think the previous post is talking about a search that will find the sibling domain names that have obtained certificates with the same account ID. That is a strong indication that those domains are in the same certificate renewal pipeline, most likely on the same physical/virtual server.
Run ACME inside a Docker container, one instance (and credentials) for each domain name. Doesn't consume much resources. The real problem is IP addresses anyway, CT logs "thankfully" feed information to every bad actor in real time, which makes data mining trivially easy.
This is publicly publishing the account ID. There is an optional extension in RFC8659 that extends it but it isn't required by any implementer. This puts that ID into a public well known location that is easy to scrape and will be (this is exactly the kind of opsec info project like Maltego love to go lookup and pull in).
Very resource constrained systems, systems where consistent admin between *BSD and Linux is important. Containers where you have reasons to break the single process practice.
Visit eBay and search for "blocked IMEI" or variants. There are plenty of used phones which are IMEI locked due to either: reported lost, reported stolen, failed to make payments, etc.
I the lines between IMEI banning or blacklisting and the modern unlocking techniques they use have been blurred a little bit and so some carriers and some manufacturers don't really want to do or spend time doing the IMEI stuff and would prefer to just handle it all via their own unlocking and locking mechanisms.
reply