A big problem with security is that you don't know what you don't know.
Want to allow users to upload image?
* Make sure submitted files are actually images
* Limit file size to prevent denial of service
* Normalize the filename to prevent directory traversal
* Add a randomized component to filenames to prevent users from overwriting each other's files
* Serve file with the proper content type
* HTML encode filename for display
Then, oops, you didn't know SVGs allowed JavaScript, so now you have stored XSS.
I don't think that's negligence, it's just not something you'd necessarily know until you saw it. And this doesn't even consider language quirks and gotchas that are even more esoteric.
> Then, oops, you didn't know SVGs allowed JavaScript, so now you have stored XSS.
Right, but presumably you're using the standard techniques to mitigate XSS, e.g. sanitizing all other text input, using an X-XSS-Protection header, using a CSP that only allows scripts that have been whitelisted, etc.
Even if you don't know that an SVG can contain js, that shouldn't put your users at risk if you're doing everything else correctly. And then when that gets caught in an audit or reported by a user or as part of a bug bounty, you can fix it. (Although if you're going to be serving up a certain UCG file type to users, I don't think it's unreasonable to expect people to Google for vulnerabilities associated with that file type.)
Developers shouldn't be expected to have perfect security knowledge or to never make mistakes, but I think it is reasonable to expect them to not be grossly negligent. I don't want to live in a world where only people wealthy enough to afford full security audits before they get any traction should be allowed to launch products, but I also think developers should be held accountable if they're recklessly endangering people.
And while you are doing all that your manager is breathing down your neck to finish the damn thing and your competitor has already released a comparative feature that you are developing.
In the ideal world, companies would give developers enough time to figure out security. But in practice, most companies/businesses just want you to ship ASAP.
> You could say the same about many hacks that involve money and assets. Judge, the software let me in! That was the original intention of the programmers!
The difference being that ethereum smart contracts are supposed to be autonomous, hence "The Code is the Contract".
If you need or rely on outside parties then why not just have a standard contract?
They are autonomous, but sometimes have unintentional outcomes. Same goes for written contracts. Sometimes they're poorly written/worded and loopholes are found.
I always understood it to be more of the automating of contract fulfillment.
That's probably not the universal take. My take is there is a place for automated smart contracts, and a place for traditional contracts. For instance, you can hardly prove beyond any doubt that a package was delivered successfully and so payment can be dispersed. Too much room for fraud there. But for many other digital services I think it would work out fine. AFAIU it's been working quite well for microgrid projects.
(Specifically smart contracts and ethereum as a whole, not really the DAO. Don't know much about that)
Maybe so. Horses got people from A to B just fine as well.
I'm not sold one way or the other yet, but the amount of trust some institutions have taken on and abused has been a bit ridiculous the past few years (and emerged unscathed themselves while their clients were left to deal with it).
Anecdotally, centralized institutions have broken many peoples’ trust in the past. It’s starting to look like a bit of a wash to me—not that I’m racing to close my accounts. Just the same, I’m not ready to write off an early tech that is still being developed and experimented on.
> Forgive me, but you haven’t been very convincing.
I don't need to convince anyone; it is a self-evident truth that cryptocurrency is wholly impractical for displacing centralized institutions. It's self-evident because it hasn't happened and there isn't even a whiff of a possibility that it could. Cryptocurrencies are a strange and interesting technical novelty, but they are closer to a video game than anything resembling a challenge to currently centralized institutions.
> centralized institutions have broken many peoples’ trust in the past
You keep repeating that but its irrelevant. Whether or not centralized institutions are breaking people's trust, cryptocurrency is obviously not a solution to the problem.
> not that I’m racing to close my accounts
Of course you're not because cryptocurrency is obviously not an alternative to a bank account in the same way that a drone is not an alternative to a car.
> Just the same, I’m not ready to write off an early tech that is still being developed and experimented on.
I'm not telling you to "write off" anything, what does that even mean? If you want to close all your bank accounts and meet up with people in the streets to trade cryptocurrency tokens in order to manage typical financial obligations then that is your prerogative; it doesn't mean that such a lifestyle has any appreciable impact on the existence of centralized institutions.
I think you're taking a lot of liberties in your assumptions about what I've said, and what the technology is or is about.
It seems to stem from one strain of thought surrounding the tech, implied by your use of "cryptocurrency" as the new descriptor and not focusing on the concept of smart contracts.
For the record, I never suggested trading cryptocurrencies as a medium for barter and exchange was a practical or desirable idea.
One viable use, currently implemented and being tested, is the use of smart contracts as an immutable record for tracking grants and other funding provided to organizations by the National Research Council of Canada:
It's not as self-evident to me as it might be to you—that's not really an explanation. You're quite aggressive in your disdain for this specific technology—I'm kind of baffled.
I'm just going to ignore all the ad-hominem comments about my "strain of thought" and your perception of my feelings towards cryptocurrency. Lets stick to the topic at hand.
Pulling this quote directly from the page you linked:
> This technology offers unprecedented levels of transparency and trust allowing public records to be searched, verified and audited at a level the world hasn’t seen before.
This is just false. What was not possible before? The page has no details just breathless hype that is typical of cryptocurrency related projects. Please offer up an explanation of how blockchain enables "public records to be searched, verified and audited at a level the world hasn’t seen before"
There was no ad hominem. I wasn't referring to your thinking. I was explicitly referring to the strain of thought that sees blockchain tech/smart contract tech as an all-in-or-nothing decentralized libertarian cryptocurrency dream. I can understand criticisms of that way of thinking. I don't see it that way, but many of your arguments seem to presuppose I do.
> This is just false. What was not possible before? The page has no details just breathless hype that is typical of cryptocurrency related projects. Please offer up an explanation of how blockchain enables "public records to be searched, verified and audited at a level the world hasn’t seen before"
You haven't explained how it's false.
It makes the public records easier to access than they previously were, and immutable. Once published, the council nor any new government can wipe the records for any reason without either a concerted effort to attack the public chain and cause a fork that becomes mainstream, or otherwise attempt to eradicate the network entirely. There is much less gatekeeping now than there previously. One doesn't have to be technical, nor do much searching to find these records. (They actually came in handy somewhat recently in discussions about TunnelBear and their funding ploys) And as mentioned, it's an experiment. The experiment is part of the Open Government project aimed at increasing transparency to the public.
> It makes the public records easier to access than they previously were
You have not demonstrated how this is so. Putting the records up on S3 is sufficient for the purpose of access.
> immutable
Immutability has no practical benefits that were not already possible using cryptographic hashing and signatures. If you disagree, please explain.
> Once published, the council nor any new government can wipe the records for any reason
This is already solved by the inherent decentralization of the internet. This inherent property of the internet is so pervasive that it is actually a serious problem for situations like "right to be forgotten" and revenge porn.
> The experiment is part of the Open Government project aimed at increasing transparency to the public
You don't need smart contracts for this, if a government is willing to be open the problem is already solved, smart contracts don't add anything to the mix.
> You have not demonstrated how this is so. Putting the records up on S3 is sufficient for the purpose of access.
That's a matter of choice, isn't it? I just demonstrated how easily accessible it was. Just because there's another method available, doesn't mean this one isn't valid.
> Immutability has no practical benefits that were not already possible using cryptographic hashing and signatures. If you disagree, please explain.
That's exactly what the smart contract and blockchain system used does. It's just another vehicle that functions in a different way than just signing the files and uploading them to a server somewhere.
> This is already solved by the inherent decentralization of the internet. This inherent property of the internet is so pervasive that it is actually a serious problem for situations like "right to be forgotten" and revenge porn.
No. That ultimately relies on the proactive efforts of others making and serving unadulterated copies of the data in question. In the form the council is experimenting with, no additional conscious action is required. The copies are made perpetually as long as the network exists. I consider that a boon for data like this.
> You don't need smart contracts for this, if a government is willing to be open the problem is already solved, smart contracts don't add anything to the mix.
You say that they're not needed. The role of the National Research Council is to research and experiment in all manners, including new technologies. That is what they're doing here. It's not a question of "was it ever needed in any form"— it's a question of: is it an improvement? Do we see benefits or detriments? Are the results net positive or net negative? And what next?
There is one way to empirically answer that question: experiment, gather data, and draw analyses and conclusions.
You continually ask me to explain myself, and I have—you've however yet to explain your assertions.
We are writing to let you know that we decided to pursue a new direction in 2019, and will be closing down the Hyper.sh cloud platform on January 15, 2019.
Over three years ago, we set out to create an open secure container-native platform. We believed that containers represented a sea change in how software would be developed, deployed, and maintained.
Along the way, we created one of the first container-native cloud offerings, the Hyper.sh platform, which utilized our open source technology, called runV, which last year was merged with Intel’s Clear Containers project to become Kata Containers. We’re proud of the platform we built, and the influence we have had on the overall container industry. We are even more grateful to you, our customers, who have deployed hundreds of thousands of containers and built out new business on our platform.
The Hyper.sh platform, while trailblazing, is not where Hyper’s future efforts lie. Moving forward, Hyper is focusing all our attention and efforts towards the upstream Kata Containers project and in developing our Enterprise Kata stack for deployment in the major public clouds.
As of today, it is no longer possible to create a new account on Hyper.sh, and on January 15, 2019, the Hyper.sh cloud service will be shut down. Per section 11 of our terms of service, we wanted to provide you time to migrate off the platform and for the next month, our priority is to help your transition to other cloud services. If you need assistance, please feel free to reach out to us via Slack or your account dashboard. On January 15, 2019 any remaining user data and accounts will be deleted from the platform.
Please start now migrating your containers and data volumes off the platform. Directions on how to migrate your container volumes can be followed here. Please note, you will not be charged for either the container or the FIP in performing the migration.
Thank you for your business and support of our platform. It has been a privilege to serve you.
Want to allow users to upload image?
* Make sure submitted files are actually images * Limit file size to prevent denial of service * Normalize the filename to prevent directory traversal * Add a randomized component to filenames to prevent users from overwriting each other's files * Serve file with the proper content type * HTML encode filename for display
Then, oops, you didn't know SVGs allowed JavaScript, so now you have stored XSS.
I don't think that's negligence, it's just not something you'd necessarily know until you saw it. And this doesn't even consider language quirks and gotchas that are even more esoteric.