And people wonder why https everywhere is such a necessity now. It should not be necessary to treat your last mile ISP as a hostile entity , but sadly, it often is.
Even if you can actually reach the people who run the ASN of your ISPs, if it something big like Cox, charter, Shaw, etc, they'll be politically unable to confirm or deny anything, and won't want to talk to you. You might get a straight answer if you are in a similarly senior position at an equivalent sized ISP that has mutual settlement free peering, such as between RCN and Charter.
If you want actual customer support these days, your best bet is to create a PR problem for the company via social media, because PR flacks are paid enough to matter.
We also have municipal fiber but they’ve chosen not to make that available for residential service which is really disappointing but … politics.
Definitely if you think of your product/ service as "premium" this is the correct model to have.
https://www.wikihow.com/Talk-to-a-Human-when-Calling-a-Busin...
But we go one further — no development on the LAN. Develop on another server at a different hosting company, and only deploy on the production host when thoroughly vetted.
Does this just mean staging/shared servers are not deployed on machines inside the corporate network, or that developers can't have their dev environment locally and instead remote in to some other machine to do their work?
I've heard of the latter in a few companies and it's always the kind of thing that makes me nope out of every applying to them.
Each dev has his own cellular connection for internet on his development box. Again, no LAN access. Corporate e-mail and cross-department file servers are on another box on each dev's desk.
The downside is massive over-usage charges for each dev's cell data (40-50 GB/month/dev over). The upside is that devs are effectively airgapped from the company, which I assume is the primary goal of all this.
Also, chat is banned. There have been efforts in the past to bring in tools like Slack, but the honchos believe that it makes the company better as a whole if we speak to each other like human beings, especially cross-department. Even if that means slowing down a project. And even if that means having to walk across campus, or occasionally driving to another part of town to another building. Phones are largely only used when off-site, or we need to talk to someone in another city.
It all sounds tremendously inefficient, but I try to think of it as being like working at IBM or Sperry in the 60's. It seems to work. The company is profitable and expanding, and has been for 40+ years.
[0]: www.cs.umd.edu/class/fall2017/cmsc818O/papers/tangled-mass.pdf
They've also done some things that I assume fell out of operating ICSI's Notary but don't make any real sense for this paper.
For example: For a real user what we care about is this cert the end user was presented for a site: Would that be trusted in (Internet Explorer on XP, Safari on iOS, a Python script on a Debian machine, etcetera) and would it be trusted in this smartphone.
And what they've looked at is, were the same Trust Stores baked into an Android phone as the above systems? But that's subtly different in a way that fogs the issue here. Example:
Suppose phone X trusts ISRG Root X1, XP trusts DST Root CA X 3, and a Debian system trusts Lets Encrypt Authority X3. Those are, to the naked eye, and this study, three completely different things. But in _practice_ for an end user it'd turn out any of the three work for trusting a vast number of certificates used on the web. Trusting one or another _does_ matter, but this paper isn't about why that is, and doesn't really explain what's going on here, it treats that sort of scenario as anomalous and potentially alarming without explaining.
The paper did remind me that ICSI's Notary won't work with TLS 1.3, which I have sort of known but not ever mentally addressed. The ICSI Notary works by peeking inside TLS sessions. In versions up to TLS 1.2, the server's Certificate is delivered unencrypted, just before both peers encryption switches on and their communications are unintelligible. This is used by the Notary and by lots of crappy middleboxes, but in TLS 1.3 the encryption has switched on earlier, before the certificate is sent, so the Notary can't see certificates any more.