Single-sourcing is a procurement strategy, not an outcome of RFP manipulation. When a purchase is put forth, the end-user[1] writes the specifications, and procurement staff[2] determines the procurement strategy. If the end-user can convince procurement staff that only a single provider can meet their needs, then they move forward with a single-source procurement.
When a specification is written specifically for a single vendor, it's not called single-source; although the end-user probably advocated for single-source during negotiations with the procurement department. Not surprisingly, this is a constant source of friction for procurement departments. End-users almost always want to buy their preferred solution, and especially in IT. There are often good reasons, but I digress.
In some contexts, the single-source procurement strategy is simply not available; usually due to procurement law. This is when you most commonly see manipulation of specification. However, competing vendors can challenge the procurement in court through a procedure usually called a "bid protest". That's not exactly what's happening here, but it's similar.
1: The person who will ultimately use/implement the purchased goods/services.
2: Usually a separate department responsible for ensuring that goods/services are "responsibly" procured.
A single-source approach requires a lengthy justification as to why they are the single option. Manipulation of the specifications so that you believe there is only one option does not require this justification because it's not explicit. In fact, it's possible that you are mistaken and another vendor could win the open (not single-source) contract.
Well, yes and no. Yes, when a single-source strategy is adopted, the spec is written for that supplier, but that does not mean that all cases where the spec is written with a specific supplier in mind are single-source bids. Sometimes it's an end-user trying to manipulate a bid so that only one supplier can answer. That's the distinction I'm trying to make.
> The problem is, in the current system, it's impossible to figure out who's doing it.
No, the problem is who is responsible for paying the fines. If the terminating carrier were responsible for paying robocall fines, this problem would be solved overnight.
But for some reason, the American people can't stomach this solution because we have a obsession with perfection in justice. The counter argument is, "The carrier isn't the one who is making the robocalls!" My POV is, that doesn't matter.
Unless carriers are obliged to participate in creating a network that supports compliance, law enforcement will always hit a brick wall when attempting to enforce existing laws. Carriers have been given _years_ to solve this problem, and in 2019 we're pitched STIR/SHAKEN... Seriously?
Make the problem more expensive than complacency and it will get solved.
> The authentication info is bigger than the call data required to set up a call.
That's not a counter-argument, it's a cop out. SSL negotiation uses more bandwidth than a vanilla HTTP GET request too, but sometimes a secure channel is more important than preserving bandwidth.
> Telcos with TDM or CDMA transmission have serious backwards compatibility problems.
More cop outs. In order to resolve problems, you have to make changes. You can't show up to the solutions meeting and proclaim that a problem can't be solved because "the old system doesn't work that way." Sometimes you must abandon the legacy systems to solve new problems.
In the US, voice time is rarely metered for domestic calls. Even discount providers offer unlimited domestic calling. The only case where you see metered calls is for pre-paid SIMs, which aren't very popular here, because you can get unlimited talk & text for $25/month.
This is hard to explain to anyone who hasn't done business with the Federal government, but your visions of national security letters are very much on one end of a broad spectrum. At the other end of the spectrum is the mundane.
The mundane includes things like contracting with the Federal government or even certain government contractors. Our company just contracted with PAE, and PAE contractors must agree to much of the same Federal Acquisition Regulations as someone doing business directly with the Federal government. One of the vendor forms was 37 pages long, and it contains sections explicitly requiring certifications that your company will comply with sanctions. The form binds the signer to personal culpability for failure.
So if you're a company contracting in this process you're tasked with preventing delivery of your product to Iran, and the Federal government gets to set the bar, not you. If you fail to meet the bar, you end up in Michael Flynn's shoes, only far less public. How long of a bet is it to expect a Federal bureaucrat will interpret compliance the same way you do? Are you willing to risk inquiry if your opinions differ?
I don't like what's happening here. I don't like it at all, but I know just enough about dealing with the Federal government that I can smell the odor from here.
Heh. Seems everyone has decided to shoot the messenger.
You may disagree with the policy, but ryaymercer isn't wrong. Living in startup land where everything is light, you move fast, and things get broken, it's very easy to overlook that there is this 500 lb gorilla in the corner just waiting to smash you into pulp for doing the wrong thing.
My guess is that something internally at Slack has triggered this. It seems likely that they're in the midst of contracting with a Federal agency, or something of the sort. When you do business with the Federal government, all manner of hell is unleashed on you in the form of paperwork and due diligence. "Negotiation" boils down to litigation, and litigation is god damned expensive.
I am not saying what's happening is right. I'm simply pointing out that this is the culmination of decades of policy and momentum within our government. Wagging our collective fingers at Slack isn't going to change a thing. What can Slack do? Let's say they pass on whatever opportunity is driving this ridiculous witch hunt. So then what? Some Federal agency doesn't get to use their messaging platform? Who cares? Nothing changes.
It all starts with asking the right questions, and ryanmercer's post likely contains the answers to a number of questions that few people are asking: what's motivating this change, who is responsible for the policy, and how can our community affect change to prevent it in the future?
I haven't commented in over 3 years, but you're the first person I've seen mention Vero Beach on HN in the 8 years I've participated. As a Vero native, your comment resonates.
> Even with Time Machine backups, you still spend many hours setting configs after a restore.
But how many hours do you spend establishing, testing, and maintaining a backup plan that mitigates the risk of spending a few hours getting back to working status after a restore?
In my experience, TimeMachine is wonderfully effective at restoring system state (including things like shell customizations, dotfiles, etc). The marginal return on investment in more comprehensive backup setup just doesn't pay dividends. Of course, there's the issue of offsite backups, which typically aren't as comprehensive as TimeMachine.
The point I'm making is that technical folks often have a hard time making value judgements as it relates to technology. Having a backup of your data is 100% necessary. No argument there. Having a backup of your system state? That's not as high a priority, because you're mitigating a future time investment with a current time investment. You have to weigh the two against each other: time spent today versus potentially time spent in the future.
In the README, this description is given of the process:
"When the list of repositories has been compiled, it proceeds to gather all the filenames in each repository and runs them through a series of observers that will flag the files, if they match any patterns of known sensitive files. This step might take a while if the organization is big or if the members have a lot of public repositories."
Digging in to the source code under `/lib/gitrob/observers/`, you'll find `sensitive_files.rb` [1]. It looks like this class loads patterns from `patterns.json` [2]. This file contains patterns that match common sensitive files like private key files, common configuration files, command history files, and config files. It has the ability to match by path, filename, or extension.
No tool can look at a file and say for sure if it contains sensitive information, but this list looks like a good start for flagging common mistakes. I'm sure the author would appreciate pull requests to patterns.json as well.
When a specification is written specifically for a single vendor, it's not called single-source; although the end-user probably advocated for single-source during negotiations with the procurement department. Not surprisingly, this is a constant source of friction for procurement departments. End-users almost always want to buy their preferred solution, and especially in IT. There are often good reasons, but I digress.
In some contexts, the single-source procurement strategy is simply not available; usually due to procurement law. This is when you most commonly see manipulation of specification. However, competing vendors can challenge the procurement in court through a procedure usually called a "bid protest". That's not exactly what's happening here, but it's similar.
1: The person who will ultimately use/implement the purchased goods/services.
2: Usually a separate department responsible for ensuring that goods/services are "responsibly" procured.