dankent

Why care about anything?

This article explains the solution in much more detail, including how the instructions for what to do were given in an obscure way in the book:

https://dreamsofgerontius.com/2016/10/05/masquerade-by-kit-w...

I'm afraid that is also not correct. Dunning-Kruger is defined as people with low ability in a domain overestimating their own ability in that domain – it does not require someone to be really good in another domain.

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

See the German TV show Dark for in interesting take on what could happen if they somehow became cyclic.

It's definitely a dilemma. I guess the sweet spot would be security systems that are well understood in house but built on existing, well understood and studied standards and theory.

A starting point might be to use battle-tested open source systems but subject them to detailed in-house analysis and audit.

That sounds like it would be a big win for law enforcement. If you can force your opponent to avoid some modern ways to communicate, you can put a big dent in their efficiency.

It's possible that paranoia might lead to criminals avoiding even technology that they could be using safely, further slowing them down.

An old fashioned system also seems like it would require more people, opening up more opportunities for human intelligence operations targeting the network.

You could always subscribe and get ad free viewing.

That way they can pay for the good service they provide without needing advertisers.

I assume wereHamster is referring to the value of the constant being changed, rather than the name.

One doesn't need to be an expert in a particular field to identify a weak argument.

For example, the author of the memo presents some citations to back up the idea that there are biological differences between men and women that might explain why more men than women choose to work in tech. I don't find that idea controversial.

However, none of the citations provide any evidence that the degree of biological difference between the male and female population is sufficient to explain the relative gender balance we see in tech.

I don't need to be an expert to notice the lack of evidence for that part of the argument and conclude that the argument is poorly made.

It is possible that such evidence does exist and I would be interested to see it but that would not change that fact that this memo, with its cited evidence, failed to make that case.

I've been using graphql recently and I have found it very productive.

Providing a lot of flexibility to the client when querying the server eliminates a lot of server side work that would normally be required in order to implement new user stories.

It does require a bit of a mindset change so I am often having to force myself to try doing things in a different way to my first assumption.

If I want to get all levels of an arbitrarily nested tree, I just query for all of the objects that are in the tree in a flat array and then reconstruct the tree on the client side using the parent/child Ids.

This is similar to what I would have to do server side if I were using SQL to get the data and then processing it to return a tree in JSON.

If I know how deep the tree will be (and it is only two or three levels) I query it directly with graphql

I'm not sure I would describe the sources as 'from here to the moon' On reading many of the sources, it was apparent that they did not provide particularly solid evidence to back up the points he was making. It was also obvious that there was a huge amount of cherry picking going on.

I thought some of his arguments were very weak and, even where he had decent points, he did not make his case in a compelling way. However, I don't think he should have been disciplined and certainly not fired. Those who disagree should refute his arguments.

That's what leads me to being reasonably sure the hypothesis is valid.

As a scientist, though, I'm always going to wonder whether there is a way to subject it to a proper test rather than just relying on opinion (no matter how much I respect those opinions)

I wouldn't take that bet either as I agree that is a very unlikely thing to happen.

Note, though, that you are using the specific word 'algorithm', where as I am talking about 'methods'. Most cryptographic failures are in how the algorithms are implemented or applied, not a problem in the underlying maths.

I would not be nearly so confident about a similar bet that applied to the actual code being widely used for encryption.

I am aware of the usual (and strong in my opinion) argument.

Every time this discussion does the rounds, though, I do wonder whether the hypothesis could be tested.

Most vulnerabilities do not come from breaking the core algorithm but rather from a flaw in how they are implemented or applied. Standardisation can lead to monocultures that become tempting targets for those with plenty of resources to throw at them.

If you're telling me I can't develop and deploy my own rockets for fun (providing I don't cause risk to others) then yes, that is thought policing.

(btw, I do develop and deploy my own rockets for fun)

You find it fantastically unrealistic that a vulnerability could be found for a well known and widely used encryption method?

Game companies are also a great example of a situation where a large group of people with time on their hands (teenagers still in high school) are motivated to look for vulnerabilities in the method used.

Have any studies been done on relative security of crypto algorithms that are either:

a) Well known, well studied but also attractive targets for attackers to study

b) Unknown (aside from the developer) until an attacker encounters a specific piece of encrypted data

It is a common assumption that well-known methods are better (and it is the assumption I work under) but does empirical data on security breaches back that up? There are plenty of examples of security breaches where 'standard' methods were being used. Are there similar examples where people using previously unknown methods have been compromised?

GCHQ and others invest a huge amount of resources in finding vulnerabilities in well known encryption methods. When they find one, everyone who used that method is vulnerable.

I have no doubt that if they really wanted a piece of data that I had encrypted with a homemade method, they would be able to break it.

However, are they going to invest the resources to do that if I am not being specifically targeted? Are they going to invest the resources to crack hundreds of different people's home-made encryption methods? Thousands? Hundreds of thousands?

If am being specifically targeted by something like GCHQ, they will get what they want one way or another.

If a vulnerability is found for the outer encryption method, additional encryption of the inner message by a different method may provide some defence.

If that is the goal, though, it would be better to use two well studied encryption methods rather than something homemade.

Following the earlier discussion (https://news.ycombinator.com/item?id=14901566) about the malicious crossenv package, I've knocked together a quick tool that might help to spot such typosquatting:

https://www.npmjs.com/package/check-typosquatters

(It's the first time I've published anything to npm so let me know if I have done anything wrong...)

It uses the list of package names from the all-the-package-names package and returns the 10 packages with the most similar names to the supplied parameter (using Levenshtein distance)

It also displays their rank based on dependent packages to give an idea of how they compare in usage.

It uses a package of package names that is updated daily.

Could a tool like this help to avoid installing a typosquatting package rather than the intended one?

I wonder whether a wrapper for npm install that warns if there is a higher ranked package within a small Levenshtein might be more useful.

I've knocked together a quick tool that might help to spot such typosquatting:

https://www.npmjs.com/package/check-typosquatters

(It's the first time I've published anything to npm so let me know if I have done anything wrong...)

It uses the list of package names from the all-the-package-names package and returns the 10 packages with the most similar names to the supplied parameter (using Levenshtein distance)

It also displays their rank based on dependent packages to give an idea of how they compare in usage.

I'm sure there are improvements that could be made - PRs welcome on the github repository.

I assume you want to represent all of the relationships on the tree in any case, so I think minimising the number of required parent-child lines would actually make representing modern relationships less messy.

You'd have a pink relationship line for each partnership (that will be the same and just as messy in both approaches)

Then you'd have one child line from each relationship line to each of the children that came from that relationship, rather than two for each child.

So in a situation where Angus had 2 children with each of Beatrix and Chloe, you would have two child lines from the Angus-Beatrix relationship line and two from the Angus-Chloe line, rather than a total of 8 lines to show all the parent-child relationships in your current approach.

If Chloe also had two children with David then your approach would add a relationship line and another four child lines whereas the standard approach would just add the relationship and two more child lines.

I really like the overall approach - definitely a nice friendly way to edit a tree.

The standard way for family trees to link children with parents is through the relationship of the parents. Did you avoid doing that on purpose?

The problem with having a separate parent/child link for every parent/child relationship is that it gets very crowded if the parents have several children.

I got better results:

Input (original) name: the-northern-trifid-nebula-8499-1920x1200.jpg type: image/jpeg size: 737.26 KB

Output (compressed) name: the-northern-trifid-nebula-8499-1920x1200.jpg type: image/jpeg size: 263.17 KB (64.30% off)

I guess your original was more optimised than mine.

A tool like this should definitely check to make sure it has actually reduced the file size and, if not, just return the original with a note that it couldn't make any gains.

Even if the primary service itself was compromised, it would be possible to have an automated dead man's switch running on an alternative service that would alert the world that you were being held incommunicado.

Of course, failing to disclose the switch to the authorities and thus allowing it to trigger could be considered a violation of a court order and lead to punishment.