One of the most frustrating things about dealing with situations like this is actually getting ahold of someone with enough experience to say where the issue is to begin with even if it’s out of the provider’s control.
I have sent a lot of log files to cloud vendor trying to find why their web hosted application was so slow (6-10 second response times on a CRM app they provided). If someone would have responded with an actual answer (your firewall is blocking traffic or try this setup etc) I could have worked with that. Instead we got nothing but stealth ticket closes and “sorry we don’t know why this is slow” responses. This article hit a nerve because you really do dance to someone else’s tune when you go to the “cloud”.
When it comes to the whole "supply chain blockchain" thing, I agree it is easy to just think "so, you just mean a signed log?", but there is actually an aspect to the whole thing that makes actual blockchains relevant here - and that's because they're both trying to solve the "double spending" problem.
In this case the thing that a middleman might be trying to "double spend" is a part with a legitimate provenance. A simple record system might show that a middleman received part A from a legitimate source, but not immediately highlight that they sold on parts B and C too, each claiming to be part A. Blockchains solve that problem in a nice way with decentralized trust.
Now, to what extent decentralized trust is relevant in a system apparently operated by Honeywell in a way that seems completely centralized... you know as much as me.
Bearing in mind these documents all start off as paper, I'm not sure that really answers the question of what blockchain adds in the way of evidence of provenance over a scanner and upload facility...
Aircraft part sales aren't trustless, and for a good reason.
Likewise which one do you think they’ll trust if the blockchain disagrees with the paper trail? The paper trail of course, which makes putting this on blockchain worthless.
Naive question, since I'm not familiar with the aircraft parts marketplace: Can the elements of the paper trail be hashed and published publicly, and can then those hashes be factored into the blockchain?
The irony is that what would actually make tangible improvements to aircraft part documentation would be more centralisation, since this allows a lot of cross validation of data on part ownership, maintenance intervals and hours/cycles data with other records regulators keep like data on flight paths and doesn't require sharing of commercially sensitive supply chain and operations information with people who don't need to know. And if you can't trust the regulator not to secretly falsify records, you've got bigger issues....
Yes, of course. But what makes the logical content of the documents/elements in the "paper trail" something that cannot be represented as text files or perhaps photographs?
In a word, trust. You can represent the information digitally, including via scanning, but you cannot digitally guarantee that the representation matches the paper copy; and the paper copy will likely hold in any disputes absent evidence of manipulation of the paper copy.
So. I, person A, am putting a part up for sail with "omitted details like final prices or provenance documents." How does blockchain solve this problem?
I, person B, am buying that part. Then I'm putting it up for sale again with a different set of details and provenance documents (because I'm a fraud or because I don't have any other documents). How does blockchain solve this problem?
Obviously a blockchain cannot magically make people do things they don't otherwise want to do.
But what a blockchain can do is model parts as tokens that can only exist once on the chain, associate data like provenance documents with each token, then model sales as transfers of the token. Finally, it can do all that in a way that you don't have to trust any single entity (though you might have to trust the consensus of a large number of entities; this is better because pressuring many entities to lie is much harder than pressuring one to lie).
Whether this particular blockchain uses that design is a separate question. I agree that if your trust model isn't distributed, a simple database will usually be better.
> Obviously a blockchain cannot magically make people do things they don't otherwise want to do.
So, what's the point, really, especially if talk about "Distributed trust" if blockchain provides nothing to ensure that trust?
> But what a blockchain can do is model parts as tokens that can only exist once on the chain, associate data like provenance documents with each token, then model sales as transfers of the token... a way that you don't have to trust any single entity
So, the details and provenance magically appear on the blockchain. Who verifies them? Who makes sure they are complete? Let me guess, some centralised/external entity?
So, there's some part associated with a token. What's to stop me from associating the same part with a different token? Or with 100 tokens? I'm guessing there is some centralised agency that verifies that a part is associated with a token through the part's serial number and that: a) no other token is associated with the same number and b) the seller associates serial numbers, and not some random numbers with the token?
I'm not even going into such things as "seller A sold part B to buyer C, received the money and never sent the part", let's start with documents, parts, tokens and associations.
Yes, you need a trusted path to go from physical reality to the token on the blockchain. But blockchains let you shrink that path down to a small number of operations that can be closely scrutinized. (This is how blockchains are similar to cryptography, where the goal is to secure a large amount of data by keeping a small amount of data secret.)
As far as how to build that trust goes, what you're talking about is similar to the certificate signing problem. There are at least two ways to do this — a hierarchy trusted by everyone (akin to PKI) and a decentralized web of trust. Blockchains let you do either or both of those things since entities can sign off on the provenance on the blockchain. You can also have multiple entities sign off on it, similar to GPG keys.
> Yes, you need a trusted path to go from physical reality to the token on the blockchain.
You mean a centralised entity that is able to verify all claims input on the blockchain, cross-reference these inputs, and then enforce the execution of the contract.
Why would you need blockchain then if you trust such an entity with so much more than just with part tracking?
> Blockchains let you do either or both of those things since entities can sign off on the provenance on the blockchain.
wat
> You can also have multiple entities sign off on it, similar to GPG keys.
So, blockchain "solves" exactly one thing: inventory tracking. And does it in an overly complicated and highly inefficient way. Everything else is entrusted to external entities.
To quote an amazing article [1]
--- start quote ---
People treat blockchain as a “futuristic integrity wand”—wave a blockchain at the problem, and suddenly your data will be valid. For almost anything people want to be valid, blockchain has been proposed as a solution.
It’s true that tampering with data stored on a blockchain is hard, but it’s false that blockchain is a good way to create data that has integrity.
Blockchain systems do not magically make the data in them accurate or the people entering the data trustworthy, they merely enable you to audit whether it has been tampered with.
How then, is trust created?
... if you look at any blockchain solution, inevitably you’ll find an awkward workaround to re-create trusted parties in a trustless world.
> You mean a centralised entity that is able to verify all claims input on the blockchain, cross-reference these inputs, and then enforce the execution of the contract.
...
> wat
My belief that you're arguing in good faith is slowly but steadily dropping. I just went over how you could have a network of such entities instead of a single centralized one. This is a policy question that's orthogonal to whether you use a blockchain for this.
> Why would you need blockchain then if you trust such an entity with so much more than just with part tracking?
Trust is not a simple yes or no thing. Blockchains make trust relationships legible and verifiable. You can go back in time and get cryptographic proofs of historical trust relationships.
I'm normally a blockchain skeptic but provenance tracking is a very good use of them.
> My belief that you're arguing in good faith is slowly but steadily dropping.
Nope. I'm just trying not to spell out every little thing that a blockchain solution doesn't provide because they should be obvious. But apparently they aren't. See below.
> Blockchains make trust relationships legible and verifiable.
They don't. They literally don't. The only thing that a blockchain solution provides is that once entered the data can't be tampered with. Which is the smallest part "a marketplace for plane parts" does.
It's easy to see if you split things into "what is done on the blockchain" and "what is done outside the blockchain via centralised entities".
On the blockchain:
- verify that once the data is entered it's not tampered with.
Outside the blockchain:
- verify that details and provenance documents are complete
- verify that the same part isn't listed multiple times
- seller ratings to aid prospective buyers
- buyer ratings (rarely public, but can be implemented to aid dispute resolution)
- verify that a seller doesn't inflate the ratings via fake accounts "buying" a lot of merchandise
- dispute resolution and arbitration when the merchandise isn't delivered, or delivered not as described, or when the buyer withdraws payment, or...
- other fraudulent activity (non-existing sellers/buyers/parts/fakes/replicas/...)
I'm definitely missing more. All of the above require trust, and non of the above are aided in any way, shape or form by a blockchain solution. As evidenced by cars' VINs, provenance tracking is a somewhat solved problem outside blockchain, and there's little to nothing that a blockchain solution can bring to the space.
> they merely enable you to audit whether it has been tampered with
That's literally the entire point here (if I've understood correctly). If anyone tried to falsify even the slightest detail, including Honeywell or an entity hosting the database on their behalf, you can be reasonably certain that you would notice it. The history of each serial number becomes effectively immutable once entered into such a database, which is presumably a very good thing given what these parts are used for.
I'd love if purchasing a used car came with anywhere near that level of guarantee about its history.
> If anyone tried to falsify even the slightest detail, including Honeywell or an entity hosting the database on their behalf, you can be reasonably certain that you would notice it.
You can only notice it once the data is entered. What's to stop me from entering false data? What's to stop me from entering multiple false entries? etc.
The article is correct that you still need oracles (of course you do), but wrong in saying that blockchains are therefore useless.
A better article would be more intellectually curious! For example, it might talk about the sorts of oracles blockchains could enable and how much of a burden they need to bear with and without blockchains.
Shouldn’t blockchain proponents be the ones to come up with such an article?
The article specifically calls out all the use cases for which blockchains have been proposed as a solution. And none of those solutions discussed the need for oracles or discussed “what sorts of oracles they would enable”.
If the data originates offline - e.g. paperwork for an aircraft part - you still need to trust whoever puts the data on the blockchain. Are they who they say they are? Are the documents trustworthy? The blockchain ensures tracability after data is on the blockchain, but not that the initial data makes sense.
So if you need to verify these aspects manually at some point, might as well have everybody work through a regular API.
However, in case of a digital currency - e.g. bitcoin - everything is generated on-chain. There is no crossing the offline/blockchain boundary. You can verify that data was generated according to the algorithm, and how it was used afterwards. This is where a blockchain is not necessarily replacable with a simple REST API.
I don't really understand how this works, but could it happen that another way of verifying is by multiple people submitting the same information? For example, the buyer and the seller of a part recording the transaction.
The comment is likely pointing out that the blockchain portion of this project is just for marketing and doesn't add much if anything to just having a database that people can pull from.
I'm not sure if that is entirely true though. The blockchain piece might provide the needed infrastructure, while providing needed authentication. I'm not really sure though to be honest. Maybe someone with more insight can point out whether the blockchain piece is really needed and helpful or just bloat.
in every article with title "company X uses blockchain for Y" the top comment is someone saying "I don't see why".
Do you have any idea about how the particular company schemantics work? How parts are sourced in this industry? What certification issues are? basically blockchain is about trust.
So you know better than the company management and deem that their CTO made the wrong decision with zero information.
You don't need to know all the details, because time and time again I have seen blockchain hyped up by people who don't fully understand it (or who are selling it) and the following runs it's course:
1. People get excited about blockchain because it's the "it thing" and people have some vague notion that it can apply to a distributed trust problem.
2. In nearly all cases, blockchain is a poor solution for the actual business need. This article, https://blog.smartdec.net/you-do-not-need-blockchain-eight-p... , which was discussed at length on HN a couple months ago, has a detailed section on why blockchain is a bad fit for "object authenticity guarantee".
3. So then what happens is people usually basically end up solving their use case with a kind of "franken-private blockchain" that more often than not is just a cryptographically signed ledger DB.
So yeah, I don't really care if the CTO is Jesus, as far as everything described in the article (which basically just describes a used-goods marketplace, gosh I've never heard of those before), blockchain is a "marketing-speak" solution.
> Before blockchain, a transaction took, on average, two phone calls and four emails to arrange, and two days to close. The sale of larger parts such as engines could take weeks of sending quotes and exchanging documentation. With blockchain, a buyer can locate a part and purchase it immediately.
I still see no reason that can't be solved with a website and a database, and I'd be willing to bet dollars to doughnuts that's 90% of what it's actually doing, with perhaps some sort of blockchain tacked on to the side so it can get a good marketing story.
Do you think banks and other users of databases don't think about fraud and corruption? What do you think we have been doing in database research for the last 50 years?
Do you know why a blockchain is useful? Its to enable fraud and corruption detection in a decentralized way. If you are centralized, blockchain is a stupid way to achieve these goals.
I expect more from the WSJ. I expect more from Silicon Valley than this kind of shameless hype.
Core banking technology is from the 70s and hundreds of billions have been invested to keep it running, and upgrading the base later is essentially impossible. This is why everything in banking is super slow and fraud is still rampant.
If you seriously think the banking system is the pinnacle of computer science you have rocks in your head.
I don't want the banking system to be the pinnacle of computer science. As with space probes, aircraft, nuclear power plants, etc., running on old tech that's had a lot of the quirks shaken out already is a plus.
Side note: Saying "fraud is rampant" as an argument for blockchain solutions is pretty funny.
It would be impossible for someone to steal cryptocurrency held in your own wallet, whereas bank accounts are routinely compromised and looted. If not blockchain, certainly there is room for improvement in our current system?
Saying you like our current system despite its high fees, slowness, and numerous deficiencies and don’t want it improved is essentially saying you want progress to halt.
> It would be impossible for someone to steal cryptocurrency held in your own wallet
That's a bizarre assertion. Both individuals and entire exchanges find their cryptocurrency wallets regularly compromised.
> whereas bank accounts are routinely compromised and looted
For which there are both legal and practical protections in place. If your card is compromised, your liability is strictly limited, and it's typically a fairly easy process to recover from.
> Saying you like our current system despite its high fees, slowness, and numerous deficiencies and don’t want it improved is essentially saying you want progress to halt.
This is the "We must do something. This is something. Therefore we must do it." fallacy.
Banking can be improved evolutionarily without throwing out the whole system in favor of a fraud-ridden platform with scaling issues. It's already happening - transfers between banks in Europe are now near real-time via TIPS, for example.
None of these improvements require blockchain, or even bleeding edge computer science of any kind.
> It would be impossible for someone to steal cryptocurrency held in your own wallet
That’s a false claim. Have you heard of people losing their wallets or about cold storage for cryptocurrency wallets to prevent others from stealing what one has? A cryptocurrency wallet is not anymore secure than the device it resides on and the security policies and practices used for the device.
> whereas bank accounts are routinely compromised and looted
Which are also regularly reverted without fuss, regardless of whether you can work out who the attacker was.
Banking is more than a ledger system. It's a ledger system and a massive web of institutional protections behind the ledger. By the time blockchain evolves the same norms, institutions, legal precedents, regulatory oversight and so on and so forth it just be a much-slower-than-a-real-database linked list.
> Side note: Saying "fraud is rampant" as an argument for blockchain solutions is pretty funny.
Because many companies using a blockchain are frauds? Many fraudulent companies use the internet too, but you likely wouldn't laugh at an anti-fraud solution based on that.
Not sure what you mean by “everything in banking is super slow”. Maybe things are slow where you live.
For money transfer (which is one part of banking), India has (had, for several years,) a few systems where money from any bank to any other bank in the country can be transferred in a matter of a few seconds or a few minutes depending on the transfer platform that the end user uses. There are no intermediaries in such transactions, like PayPal or something else. Nor are there any electronic systems that take a few days for transfer during working days.
> This is why everything in banking is super slow and fraud is still rampant.
This depends very much on jurisdiction. The USA has slow banking and high fraud because of the clearance system and because of weak identification of account-holders.
In Australia, the UK, Europe and elsewhere, clearance systems are either faster (same-day), or allow direct bank-to-bank clearance, or both. Australia has strict banking identity laws, making it very difficult to open fraudulent accounts.
"After several years of trying to manage these issues with Kerberos, we decided to redesign the system from the ground up.."
I am curious, is there anyone who went the opposite direction direction and implemented a new Kerberos library or setup?
So, several places, such as Stanford or Morgan Stanley, have sophisticated Kerberos setups using something like Russ Allbery's Wallet[0] (Stanford) or Roland Dowdeswell's OSKT[1] (Morgan Stanley, Two Sigma) stack.
For example, OSKT is a self-service toolkit that lets users build up access controls for clusters, "role accounts" (user accounts for running application automation), and what not. Users use "krb5_prestash" to indicate what hosts should have what role accounts' credentials (the user must own the hosts and role accounts) and krb5_keytab to get keys for services on hosts they are allowed to run. A nifty trick is to have wildcard DNS A RRs for hosts so that one can have HTTP/${USER}.$(uname -n) principals (and keys for them) on any host the user can login to.
All of this is high-performance and self-service. Users don't need to file JIRA tickets or whatever to get their keys for their services.
Self-service credential provisioning is absolutely essential to successful deployment at scale of any authentication system one uses, whether that be Kerberos or PKIX or DANE or anything else one might find or invent.
I understand this situation applies if the “developer resource” is a direct report. However in many instances the dev may have multiple projects going on at once and there is some miscommunications on project priorities. Yes, this has happened to me and it’s why I abhor the phrase “developer resource”
The thing that I enjoyed being the solo developer most is that I got to make all of the software design choices. I set up the project the way I wanted to and code in way I felt would best to ship the product. Loved that aspect of it.
That being said I would do two things differently.
1. Be hyper about testing.
If you are the only dev working on a project test,test and test more. Write good unit tests. Have your fellow co-founders test and sign off on a feature before going to prod. If you are working hard it's easy to miss the obvious. Test it all.
2. Find good ways to communicate where you are and what you are doing.
Some features take longer than others. It drives non-technical people crazy (Why did this feature take an hour and this one a week?) but that is the hard fact of software dev. Use a Jira board or an email, whatever will let your co-founders know what features are where. It really saves on the annoying status update requests in person or over email that disrupt your day.
Good Luck :)
I am moving in this direction after having taken a few coding challenges and not heard anything back from the company. If I am going to spend time on a coding challenge, I am expecting at least an acknowledgment that I am no longer being considered for the position. Coding challenges are a time commitment and if a company can't even be bothered to commit to at least being polite about it, then it's a clear indication of how they view employees.
I respect that fact that CrowdStrike and others have spent the time with the api and made life a lot easier for others. As someone who has spent more time than he wanted with the Office 365 API I am a fan of people who make my life easier. That being said I am not buying the drama that these API's have been hidden.
I can understand about being suspicious of the NSA after the whole Dual_EC_DRBG fiasco. However these designs are not unknown throughout the industry (ARX having gotten some heat lately from the Keccak people). Is there some technical reasons these designs should be disallowed aside from "We don't like the NSA".
My technical (but probably mostly insignificant and unexploitable) issue with speck/simon is with the key schedule, which has somewhat slow diffussion with key length >2 words.
Also the key schedule is trivially invertible (I intended to include that fact in my original comment, but wasn't sure of that, now I'm).
On the other hand this seems like deliberate design choice in order to remove any unexplained constants from the design (the counter in the key schedule seems "explainable"). Alternative with the same design would be to supply the key into the key schedule as subkeys (cyclically or so), which would then mean that initial state is some kind of unexplained constant (there is good reason why {0,0} is not good initial state and given the fact that it comes from NSA any other value will seem suspect)
Edit: the fact that key schedule is invertible does not decrease the security as long as it is used as block cipher (in fact on this level of analysis it slightly increases the confidence in the design as long as it is only meant as block cipher). On the other hand it means that insecure constructions of hash function from block cipher are probably not only theoretically insecure, but readily breakable by NSA. (I wouldn't be surprised if this was the motivation of NSA, because for many IoT applications one is more interested in authentication than in confidentiality)
If your goal is to make money on something, then yes I agree with the author's points. However the whole goal of side projects is to have fun with new languages, frameworks etc.
Building on that even, the most fun I have had at "networking" was listening to other developers talk about some of the problems they are working to solve in their jobs/areas of interest. Half the events I enjoy going to are partially motivated by "I wonder if so and so found away to fix x issue"
I have sent a lot of log files to cloud vendor trying to find why their web hosted application was so slow (6-10 second response times on a CRM app they provided). If someone would have responded with an actual answer (your firewall is blocking traffic or try this setup etc) I could have worked with that. Instead we got nothing but stealth ticket closes and “sorry we don’t know why this is slow” responses. This article hit a nerve because you really do dance to someone else’s tune when you go to the “cloud”.