ekiru

> You're skirting around the key basis of almost all systems of justice: you do have a right to autonomy as long as you don't violate other's equal right to the same. This is basically the Non Aggression Principle, and it has the effect of maximising personal autonomy.

Many modern legal systems thoroughly limit the autonomy of individuals with regard to suicide, either by directly criminalizing it, by criminalizing any assistance others might provide a suicidal person in achieving that aim (in some systems even criminalizing merely failing to prevent a suicidal person from succeeding), or by authorizing other people to use force to prevent an individual from achieving that aim.

Suicide is an extreme case, but it's an extreme case in which usually no one's autonomy or body except the suicidal person's is involved. If an absolute right to our own bodies where it does not interfere with the rights of others is a key principle of our legal systems, then we should expect our legal systems to place no limitations on it, beyond at most restrictions aimed at preventing others from coercing an individual to commit "suicide", but this is not what we see in almost any modern legal system (if anyone has an example of one which does fit that expectation, I'd be curious to hear it).

First, the person above you didn't say anything about caring about the underlying ideology; they said that they cared that the project seemed to them to be an art project designed for ideological purposes and unlikely to succeed as a result.

Second, people definitely do choose their linux distributions based on ideology. The Debian project, in particular, has a very well established ideology. They also choose which distributions they spend money on or donate money to (the relevant comparison to purchasing stars as discussed here) based on ideology.

Third, Urbit is a different category of thing from a Linux distribution. Urbit is a network. A network designed and organized based on a particular principle can impose that principle on the way that people on the network act, interact, and relate on the network in ways that a Linux distribution cannot. I am not certain whether this accurately describes Urbit. Statements from the project and its developers have suggested to me that this has been a goal, but they may have retreated from that since.

Making the decision seems a lot easier to me when the monitoring software explicitly markets itself to and supports domestic abusers.

The government of Russia in the 1920s was not composed of peasants; it did not even consider peasants as its allies. It largely considered them to be class enemies of the proletariat and counter-revolutionary. During the 1920s, it began its efforts to collectivize them. The peasants resisted these efforts initially. Ultimately, the effort succeeded only when the Russian government expropriated the peasants' property, and it deported, it imprisoned, and/or killed millions of them. That occurred mostly in the early 1930s, but Russian rural policy in the 1920s was a persistent struggle against the resistance of the peasants to the government's policies aimed toward collectivization. Saying that Russia was not ruled by peasants is not a "no true communism" argument, it is an accurate reflection of the continued efforts of the Russian government throughout that period and beyond to coerce the behavior of the peasantry and to break down their existing social structures and communities.

The problem isn't that multiple time zones give the same local time at a particular time; the problem is that a person may experience the same local time multiple times during a day due to traveling or summer time.

Suppose I'm coming back to Chicago from a trip to Japan, and a friend wants to get an early dinner when I get back. One frequent direct flight from Tokyo leaves NRT around 6 PM and arrives at ORD at 4 PM on the same calendar date. Before I leave Chicago I set an event for meeting them at our favorite restaurant at 5:30 PM. Should my calendar remind me about the event when it's 5:00 PM where I'm at waiting for my flight to board at Narita or at 5:00 PM where I'm at back in Chicago?

It's also possible to experience a particular local time zero times on the date for either of those reasons.

There is an approach (called Supersingular isogeny Diffie-Hellman or SIDH) using certain types of mappings between elliptic curves being researched that _may_ be secure in a quantum setting. (edit to add:) I think this may be what the grandparent poster is referring to by "trying to adapt elliptic curves".

It can inline library functions, since, at latest, 1.4.2 (this is just what I happened to have handy on this computer). It's pretty easy to test by writing a package containing a simple function like "func Square(x int) int { return x * x }", compiling a main package that imports that package and calls Square, and then disassembling the executable to see whether it calls Square or inlines it.

> but it's not impossible for hitting a pedestrian to be a non-crime because of the absence of the mental state required for any applicable crime.

Out of curiosity, under what conditions would this be the case?

Two more splits: In my hometown (in Tennessee), the split was originally K-3/4-8/9-12, but around 2000 they completed the construction of a new high school, so the old high school became the new junior high and grades 4-8 got redistributed so that it was now K-2/3-5/6-8/9-12.

'hannob is referring to the reliance of QKD protocols on "an ordinary public communications channel, assumed to be susceptible to eavesdropping but not to the injection or alteration of messages." [0] This means that, unless your authenticated channel itself cannot be broken using quantum computers, using QKD with it will still not let you do secure post-quantum key exchange. If you have a authenticated channel that can't be broken with quantum computers, how did you implement that without either already having or arriving at a shared secret? (If you already have a way of securely arriving at a shared secret, then what do you need QKD for?)

[0]: at page 177 in http://researcher.watson.ibm.com/researcher/files/us-bennetc...

> The affected party (in this case Cloudflare) has incentive to handle the situation in a way that's limit the damage to their customers and their customers customers (which are the ones affected).

Cloudflare has a much stronger incentive to handle the situation in a way that limits the damage to their reputation. As you note, researchers also have an incentive to maximize the benefit to their reputation. But the incentives for P0 are much more closely aligned to the interests of the public here than are the incentives for Cloudflare. The information revealed by the bug is indeed really bad, and there's likely no possible way to tell which of Cloudflare's customers were affected, much less those customers' users. No company wants to acknowledge "yeah, a bunch of our customers' data was compromised, and we have no possible way to tell whether your data was among the data compromised". Their incentives push them to downplay the impact; to accurately describe the potential impact to their customers would probably be disastrous for them as a business. In contrast, downplaying the impact would be contrary to P0's incentive to benefit their own reputation.

If you consider the establishment clause and the concept of judicial review of the actions of Congress and the President to be nonsense, you can expect to be consistently disappointed in the sensibility of the functioning of government in the United States.

Resolving either complaint will likely require a constitutional amendment; the Establishment Clause is literally a clause in the US constitution, and the judiciary's role in interpreting the law and in deciding when a statute or regulation is contrary to the Constitution has been practiced throughout the entire history of the US since the Constitution's ratification.

Recognizing when people are lying is an important part of CBP's job. They're trained specifically to do it. It's unlikely that you're better at lying than they are at noticing that you're lie. Lying to them will end poorly.

> Even if WhatsApp's crytpo is as flawless in implementation as we'd like FB still has access to all that metadata.

Note that this argument is even more problematic for OpenPGP-encrypted email, as such email sends all metadata and some message data in plaintext.

That would directly contradict Musk's claim that the UAW paid the employee to join Tesla.

> you must necessarily provide justification so that another audience, which would want to make sure that you're not selling snake oil, could verify your why

Much of the audience that has the expertise to effectively verify the wisdom of the advice in such a document will have already encountered the views it contains and will be familiar with the reasoning behind those views already. None of the guidance in the article is likely to be something they're hearing for the first time. Even if they disagree with something in the article in whole or in part, they already know why the people who compiled the article likely believe it.

It is good for there to be more detailed explanations for interested non-experts, and there have been a number of more detailed explanations of many of these items elsewhere on the internet. But for most people it's more important to know that, for example, a recent iPhone is their best choice for a secure phone than it is to know the details of why experts on the topic have come to that conclusion, just like it's more important for most people to take a flu vaccine each year than it is for them to understand the process by which that vaccines was formulated.

It may be true that "shame only works inasmuch as you believe folks have a point" (I'm unsure), but it's certainly not true that shame only works when the folks doing the shaming have a point. People often feel shame when people criticize qualities that they do have that I think we'd both agree are not shameworthy. As well, some people have a tendency to, when they see criticism of a vaguely-specified group to which it is remotely plausible that they are included in, include themselves in the criticized group and feel shame as a result.

These objections do not necessarily imply that we should not attempt to publicly shame shameworthy behavior, but such tactics do harm some people who are guiltless (unless "guilt" here is intended to include feeling a sense of guilt without having actually done something wrong, in which case the statement seems tautological) and guileless. So does asserting that they don't in a public setting like this, independently of whether the particular individual the assertion is deployed against is themselves worthy of disapproval.

That's fair.

Why should the taxi union's decision to strike impose an obligation to strike on others who are not part of the union and had no input in the decision to strike?

> We also agree that Signal is a more secure alternative.

Signal is only a more secure alternative in _some_ threat models. The most obvious counterexample is that, in some contexts, using WhatsApp marks you as a person who owns a smartphone, while using Signal marks you as a dissident. There are other contexts where losing messages while not being actively attacked (not even just due to this design decision; Signal ultimately just does not have as reliable infrastructure as WhatsApp) is more dangerous than WhatsApp's resend behavior.

I think most startups, particularly the ones taking investment, rather hope that 10% of the company will not be cheap.

I think that could mostly work. The placeholder message would have to be of identical length to the original and the resent message would have to use later sequence numbers/message ids (or whatever is used to identify individual messages) so the server couldn't tell that the placeholders were placeholders.

One issue is that it would mean that, in the case of an active attack where the server substituted a key they knew in place of a legitimate new key from the user, the server would be able to decrypt the possibly-placeholder resent message and determine whether the user had notifications on. If the user didn't, they'd know that they were safe to continue to attack the user (this attack is more risky than the passive one on the blocking resend without placeholder messages protocol, of course). So, this does improve the security of the protocol for users with security notifications enabled, at the cost of making users without those notifications less safe. I'm not sure how the tradeoff should be balanced here (just as I'm unsure if the UX tradeoff of having the option of not receiving security notifications is worth it...).

If resending undelivered messages to new keys waited for confirmation of the new key when safety number change notifications are enabled, then users without those notifications enabled would continue to immediately resend undelivered messages to new keys while users with the notifications enabled would not resend until the user manually OKed the change. The WhatsApp servers know (or can know) whether users have outstanding undelivered messages and can observe whether users resend them immediately after a key change. As a result, if resends after key changes waited for user confirmation with security notifications enabled, whenever a user changed keys, WhatsApp would be able to tell whether any of their contacts who had undelivered messages to that user had the notifications enabled by observing whether those contacts immediately resent the messages or not.

The reason tptacek looked at the illumos source code is because I mentioned to them that a blog post you've previously linked to about the Solaris random devices [1] appeared [2] to suggest that the entropy provided by KCF randomness providers is given out fairly directly by /dev/random (with each byte of entropy XORed with the byte returned 1024 bytes earlier). Do you know if that specific thing has been changed to stop being true since illumos diverged? Do you know if urandom has been changed to no longer always run things through fips_random_inner (as illumos does and Darren Moffat's blog post says Solaris does)?

[Edited to add: it looks as though the tweeting questions-at Darren Moffat protocol has been initiated: https://twitter.com/tqbf/status/817496091759362048 . It's also worth noting (which I failed to do previously) that two of the three random providers in the blog post are described as doing their own hashing/similar processing of the entropy bytes they provide to the random pool, and the other one appears to do so from the illumos source.]

> Use of urandom contrary to official guidance is not recommended.

This is, I think, a case where using the passive voice is suboptimal. The official guidance obviously does not recommend using urandom contrary to official guidance, nor do you. Some others do recommend it, as this whole argument shows.

More substantively, this is the part of your stance that would be, as tptacek previously suggested, equally applicable to Linux urandom prior to Linux fixing their man pages. At that time, the official guidance on urandom was that it was inferior to random in general instead of solely in the one specific case of requests before the kernel CSPRNG has been seeded. If the official guidance is incorrect about when and if urandom is inferior to random, then use of urandom contrary to official guidance should be recommended.

[1]: https://blogs.oracle.com/darren/entry/solaris_random_number_...

[2]: The blog post only briefly mentions the rndc_addbytes and rndc_getbytes functions where the entropy provision and randomness-extraction bottom out, so it is possible that it just omits the details of any additional processing performed at that level. But it at least does not mention any further processing performed on the bytes from KCF providers except in FIPS mode.

This is indeed trivial to implement for Go in the sense of "implement" which allows for just calling out to guru ( https://godoc.org/golang.org/x/tools/cmd/guru ).

I think you're right that that is not the point of HN, but I think HN attempts to automatically (and the HN moderators attempt to non-automatically in some cases) detect various kinds of voting abuse, including that kind. It's possible that these detection mechanisms are flawed and that this story was upvoted in that way but managed to get past those mechanisms, but another possibility is that people found the concept interesting and upvoted for that reason (or hoped for it to produce some interesting discussion). Many of the other comments (most of which do post-date your original complaint, of course) do seem to support the hypothesis that some HN users would find it interesting.

With that said (and assuming you have sufficient karma to flag stories), I think that believing a story to have reached the front page via such abusive voting would be a good reason to flag the story, which will bring it to the attention of the mods, who hopefully would be able to determine whether anything improper was in fact going on.

> That being said, I see a lot of people pointing to "incivility" as a problem in political threads. That is incredibly wrong. The problem in political threads is twofold: (a) people civilly arguing without actually acknowledging each other's points at all, (b) hateful rhetoric which destroys a sense of community.

I think you're right that both of those are problems, but they're not the only problem. Incivility is also a problem in political discussions here lately. Another problem lately is that discussions to which a political discussion is only tangentially relevant get derailed by political discussions that exhibit these problems.

> If you want evidence of how civility is not the problem, take a look at this thread where a long-time commenter (with >12k karma) civilly, calmly proposed the mass deportation and/or murder of Jews: https://news.ycombinator.com/item?id=13056816

I disagree with this for two reasons. Firstly, if people could civilly propose the mass deportation and/or murder of Jews, then that wouldn't show that people proposing either that or innocuous things incivilly is not a problem (only that incivility is not the only problem). But here specifically, I don't think that commenter spoke civilly, any more than "No offense, but <some insulting or offensive thing>" is polite (indeed, less so, as the commenter made even less pretense). The civility of discourse isn't independent of the content of that discourse.

It doesn't have to be, but it may be that it still should be the solution to that problem. It makes sense for, for example, news sites to disable comments on some stories because the comments aren't the most valuable portion of the site: the news is.

But I think that in large part the value of HN is in the comments. If HN isn't able to discuss a story productively, what's the point of that story being on HN?

I think that "Don't run several pieces of years-old third-party software with multiple publicly-known code execution vulnerabilities as root/SYSTEM on possibly malicious input" is a bare minimum requirement to demand of a piece of software whose entire purpose is to analyze untrusted data to prevent malicious code from executing on our machines.

If it's unrealistic to ask that of AV software, then I'm not sure how this works out to be an argument for AV.