Hacker Newsnew | past | comments | ask | show | jobs | submit | merrickread's commentslogin

We're only beginning to really understand Autism, Asperger Syndrome, and countless other cognitive states.

So programs of this nature are wonderful to see — they create the opportunity to learn from and work with people who think differently than the general population.


Couldn't agree more. We're using some blockchain technology to solve specific problems at my company. It's a part of our stack, but we don't mention blockchain unless someone specifically asks.

Blockchain is sensationalized beyond belief. I can't wait for the rose tinted glasses to fall off and we realize it's just a data management technology for specific use cases.

I think the biggest danger to the technology is that the community focuses on "blockchain will change the world" not "how can we make this better".


I've always wondered about this- all the hype about 'Blockchain'. Can you explain this a little bit more? How do you have a blockchain without bitcoin/ether or at least mining? Isn't that just a glorified database? What does a (I assume centralized) blockchain do for your company that a database or any type of electronic ledger cannot do?


Yes, right now it is completely a glorified database. It's always been a database. It's a different database.

We're using it for compliant sharing of and collaboration on private information records between non trusting organizations and businesses. You could do this with something like a highly distributed Cassandra cluster. But some of the inherent rules to a blockchain allow us to provide higher security, higher data persistence and availability between nodes, auditable records, and accountable participants / contributors.

And it's not centralized, it's completely distributed - just not publicly available to anyone who can download a mobile app.


If there is no mining isn't this just like git and other systems that use merkle-trees under the hood?


This does a pretty good job of explaining the differences if you're curious: https://medium.com/@philippsandner/comparison-of-ethereum-hy...


how to get people to care about your computer science work

1. s/Merkle tree/blockchain/

2. there is no step 2


It's a database that is designed to be very expensive to update but easy to verify. If someone still manages to update it with an invalid state other nodes will validate the new block and not accept it.


The trouble with blockchain is that the technical discussion is often overshadowed by investment narrative. If you'd like to learn more about the actually useful applications of the technology beyond "the future of money", research Hyperledger and smart contracts. We recently launched a free introductory course on the subject of blockchain if you are interested in the business use case: https://cognitiveclass.ai/courses/blockchain-course/


I'm rather more impressed by the DAG systems than the chain. A tree always seems more sensible that a linked list.


If you're into consensus algorithms take a look at Algorand:

https://people.csail.mit.edu/nickolai/papers/gilad-algorand-...

It has some novel approaches to node / data agreement.

Also take a look at the many projects Hyperledger projects. Hyperledger is incubated by The Linux Foundation. Their attitude towards open source development is that of purely technical curiosity and experimentation. Brian Behlendorf is directing the project so it's in good hands. He speaks about this attitude here:

https://www.youtube.com/watch?v=pr4Hb0jb0lo


Solidity is just the first try. I built a couple projects and ideas with it - found it to be a very uncomfortable language.

On the other hand you have Hyperledger, it's "contract" code is Go. Widely adopted language that was basically designed for networking efficiency.


I dream of seeing a "security first" development process adopted ..


Are you sure about that? You do know most organizations will implement that as a huge amount of bureaucracy for every commit, rather than proper man-hours of security-oriented development.


Only because most organizations don't know how to be effective at security.

It's not hard. You don't actually have to change much. You just have to schedule regular pentests, ideally every couple weeks.

Pentests protect everyone because it's our job to worry about all of the security flaws that you can't possibly be aware of in your normal day-to-day development cycle. There's just too much for any organization to know about except security companies. This way you can focus on development and we can focus on pointing out how to fix what's broken.


Pentests aren't a magic bullet either. You can easily find a consultant who isn't going to rip you a new one.

Security is a mindset. Any "checklist" approach will eventually devolve into ass-covering by an organization that is not internally motivated to run a tight ship. Legitimate variances will be hassled to no end, while actual security vulnerabilities will be ignored.


In the real world, one of the only reasons people get pentests is because another company is forcing them to. That results in a document saying company B is secure.

This is a very effective approach at cutting through ass-covering. Company B has to fix the security problems uncovered in the pentest. There is no other option. And I've seen it take products from "SQL injection by typing an apostrophe" to "It'd be very difficult to exploit this app."

If that's not proof that pentsts are effective, then I'm not sure what would be.

We like to say that security is a mindset, but developers have way too much on their mind to be aware of every possible security vector. It's easier and more effective to punt and let us worry about it instead.


There's different levels of penetration testing too. I worked at a SaaS startup and when we got our first big customer they demanded we get a third party to run a pen test on us. They basically ran their script and gave us a report. There might have been some minimal going back and forth about some false positives, but that was about it. That's better than nothing, but may not be what some of the more technically/security minded folks here at would consider a real pen test.


"It's not hard."

No, it is not, you just need skilled people working on it. Oh, those people want money for it ...


Exactly. It's not hard, it just costs some money.

It's exactly the same as physical security. You build fences and buy locks. You pay people to keep an eye on things. You take insurance to cover the rest of the risk.

Nothing hard, no new inventions required. It just takes some attention and cash. It's part of the cost of being in business.


Wait, the hardness of information security comes because it has to be built-in everywhere since everything is connected and so everything is a potential attack surface.

It's not impossible but it requires a somewhat universal attitude change.


I want to agree with you in principle, but in practice it's not possible to be secure with just an attitude change. The attack surfaces have grown too large. Keeping track of all possible vectors is a full-time job in itself. You either need a dedicated security person or regular pentests. And honestly, regular pentests are probably more effective.

It's a positive statement though: it is possible to be constantly secure if you just get a pentest every few weeks. Big companies can even afford to make it a requirement of their release cycle.


> Big companies can even afford to make it a requirement of their release cycle.

Oh man. I have a peer who works for a very large international company. They require pentests in their release cycle. What could go wrong?

Turns out that pentesting isn't in the final portion of their release. They tag a release candidate (e.g. v5.7.0-rc), send that build to the pentesters, then fix other integration and user-acceptance bugs while the pentesters are working. The pentesters may greenlight v5.7.0-rc when it's really v5.7.3-rc that's shipping, and the pentesters are none the wiser.

Security only works when the culture supports it.


Attitude change in the sense of not being willing to allow inherently insecure architectures - management always moving the company towards secure-on-principle architectures (not that I'm qualified to say if it's a good example but Google's BeyondCorp is an example of aiming to make everything secure on principle meaning not leaky on principle). That added to any pentesting or other necessary immediate security measures.

The impression I have is that today's event was the result of a lot of companies allowing insecure-on-principle architectures like a zillion apps each with their own update structure (random Ukrainian enterprise app supplier gets penetrated and the whole world goes down). A pentester might never be able to find that vector until that app supplier leaves their door open or someone finds out about them for example.


And people skilled at picking the skilled people and a willingness to actually do what the skilled people say... when those skilled people aren't necessarily the same as the managers shouting managementese...

And this also collides with the willingness to do anything to save a couple of dollars and once that dictate isn't flowing through every once of the company's blood, who knows what will happen.


Pen-tests show the presence if vulnerabilities, not their absence.

To make secure systems, we need to take the (very) difficult road of working our systems bottom up and proving the absence of vulnerabilities and defining the boundaries of safe operations.


What I really want to see is security being integrated into the development process as a conscious tradeoff teams have to make.

When a new feature is proposed, it's rare to hear someone object on the grounds that it could potentially add new vulnerabilities, but in the long run an approach that recognizes and considers those risks would be beneficial.

At the same time, this is incredibly hard to do - managers celebrate employees who develop things that look cool and awesome, not employees who can mitigate risk and manage security effectively (hopefully this changes, but I can't imagine that many unaffected CEOs are calling up their sysadmins right now and congratulating them on their diligence in making sure all their machines are patched).


Definitely a problem. People (incorrectly) compare vulnerability scanning with pen testing. Vuln scanning often is a component of a pen test, but we do a bad job explaining the distinction. Pen test should attempt to use the app(s), maybe test the people and process, not just profile the software versions and complain they are out of date or misconfigured.


[flagged]


Do you think the engineers at Microsoft who were responsible for these badly designed and buggy systems wouldn't have been able to get credentials?


What does it have to do with credentials?


yup, the vast majority of these unregulated ICO's are borderline fraud and stand only to hurt the ecosystem which they're trying to enrich. I expect there will be a heavy correction towards the end of 2017.


The hyperledger equivalent of ethereum's smart contracts is called chaincode. I'm playing around with it now - so far enjoying it much more than smart contracts.

https://github.com/IBM-Blockchain/learn-chaincode


I completely agree, it sounds like the forever present problem of wrong tool for the right job.

However it offers the potential to approach problems in a fundamentally different manner. I find myself incredibly curious and fascinated with how it works - then immediately rejected once I see discussions on HN about the blockchain.

According to your bio you've been programming for many years - is an apprehension towards something new a common pattern you've observed?


To many people on HN, blockchain isn't new; many of us have gone through the incredibly curious and fascinated stage around 2011-2013 and are now in the cynical and grumpy stage. If you're curious about this stuff keep learning but HN and Reddit probably just aren't good places to do so.


Turnstyle | Toronto | Senior Front End Engineer | Full Time & ON SITE | https://getturnstyle.com/careers

We are looking for a Senior Front-End Engineer who is motivated to tackle building complex web applications. We are looking for someone who can bring UI/UX designs to life while maintaining a robust client architecture.

You will be taking a leading role on our Front End team, working with the Design, Product, and Back End teams to build the next generation of our product.

Our development team is a very open team and we believe in progression through strong ideas, not big egos.

We are highly collaborative, everyone here is very approachable and happy to share their knowledge.

Personally, I have been working here for 2 years and can say it's an amazing place and culture to be a part of.

If you're at all interested send me a message or hit apply under the job posting on our site (it links to my email).

I'm happy to chat about the role.


We're in the process of harmonizing our entire team (9) to use Vagrant in a VirtualBox. For the most part it works, but we run into issues regarding VB memory consumption crashing machines. Minimum 8gb ram machine.

Do you have any advice on how to keep the memory footprint low?


Are you using 5.1.x? It had a ton of performance improvements over 5.0.x and earlier.

I regularly run 30-40 VMs at once on my dev server at work (40 cpus, 384gb ram), and I haven't had any problems like this there or at home...


Amazing, we are using 5.0.x I'll see if that helps. Thank you!


Another random thing I just remembered: if you're doing work in the VMs that is heavy on network I/O, try turning GRO off. We saw a big performance increase by doing this: https://github.com/contiv/volplugin/blob/master/Vagrantfile#...


One other thing: VirtualBox 5.1 is only supported by Vagrant 1.8.5 and newer, but 1.8.5 has a 100% showstopper bug where the SSH key inserted into the VM is not chmod'd correctly and OpenSSH refuses to look at it. Use 1.8.6 or newer instead.


The solution often lies in a good distraction


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: