While applauding the stated mission of Open Whisper Systems to make cryptography usable by large numbers of people I think it is fair to hold Moxie & Co. to the same high standards to which they held PGP: https://moxie.org/blog/gpg-and-me/
The journalists who depend on it struggle with it
and often mess up (“I send you the private key to
communicate privately, right?”), the activists who
use it do so relatively sparingly (“wait, this thing
wants my finger print?”), and no other sane person
is willing to use it by default. Even the projects
that attempt to use it as a dependency struggle.
Breaking this up into constituent parts and trying to guess whether those standards are met seems to leave us somewhere in this territory:
1) Journalists communicating with WhatsApp struggle with it and mess up.
Given the confusion around under what circumstances one can communicate securely with WhatsApp ("Is it OK if I have two checkmarks? Is it OK because Facebook would never let a government have access to the RedPhone part?")
2) Activists who use WhatsApp do so relatively sparingly. I have no idea on this one. I hope they're using Signal and/or GPG with all their attendant bother, complexity and confusion though.
3) No other sane person is willing to use WhatsApp by default. Hmmm.. more confusing value judgements. Is someone that uses a communication method open to abuse by corporations and governments "sane"?
4) Dependency struggle. AFAICS no other projects can piggy-back off WhatsApp because it's proprietary and closed. So the user base can't scratch their own itches. OK, so what about Signal? Sounds like the dependency on Google Cloud Messages and Play Services can be hacked around with great difficulty.
I dunno. Fair play to Moxie and Perrin for what they've done, but so far GPG looks like a better bet for actual secure end-to-end communication, using an already existing, widespread distribution mechanism which is widespread and redundant: email.
Reports of GPG's death may have been grossly exaggerated.
Can you find a single practicing cryptographic engineer who will go on the record as saying that PGP (in any of its incarnations) and email is better than Signal Protocol for message encryption?
If one is going to be paranoid, then one should at least be consistently paranoid.
v1 of the internet as used now seems wildly naive of state surveillance.
v2 may be better, but if most traffic goes encrypted, then there are going to be a lot more attacks (both legal and extra-legal) against the nuances of implementations.
v2 is certainly an improvement on v1. But one of the reasons v1 was deployed is because we believed things like "The US government would never tap traffic at the backbone" or "The US government would never tap private links between data centers."
Valuing both, I think it's important to keep eyes on the future so in 10 years we don't look back on statements like "The US government would never compell Google / Microsoft / Facebook / Whisper to distribute a poisoned version of their application" with the same amount of surprise.
I don't understand what this has to do with whether we should use risky, leaky cryptosystems like PGP over things like Signal that were designed specifically to deal with these threats.
I'd agree with the top of Unman's comment about striving for more, while disagreeing with the bottom.
Signal is better than PGP.
Running crypto without PFS in this threat environment is an irresponsible bet to make with data.
My point was that failing to continue to maintain vigilance, even if it sounds paranoid, is also irresponsible. Unless one is willing to be that we have a perfect crypto system, some amount of humility (as evidenced by Moxie's speech) is warranted. Else we'll be talking about Signal in 20 years in the same way we're talking about PGP.
Signal is a system designed always to be encrypted with no plaintext opt-out, with secrets that change automatically over the life of a conversation (which could last years) so that a single point-in-time loss of secrecy has minimized damage, with no exposed message metadata so you can't accidentally betray your conversation with a dumb subject line, and with deniability so that someone wiretapping you can't cryptographically prove you to have said anything.
> 4) Dependency struggle. AFAICS no other projects can piggy-back off WhatsApp because it's proprietary and closed. So the user base can't scratch their own itches. OK, so what about Signal? Sounds like the dependency on Google Cloud Messages and Play Services can be hacked around with great difficulty.
There is a pull request that got some quite thorough code review by moxie recently that gives users the option of _not_ using GCM, but it won't be merged until call/video support is implemented with webrtc (because it can't support calls over websockets, and just not being able to call some users isn't an option.)
And GPG is too hard for people to use. I have helped journalists with GPG, and even intelligent somewhat tech-litterate people struggle with the concepts of it. Look no further than Glen Greenwald, who almost wasn't able to communicate with Snowden.
> Front brake will flip you over in an instant, I know because I've done it, even at slow speeds
That's because you simply do not know how to ride a bicycle. In such a situation you need to get your weight back behind the saddle and modulate the application of the brake.
O.P. is one hundred percent correct that you do not need a rear brake -- and I speak as someone that rode for several years in without one including in SF.
I "simply don't know how to ride a bicycle?" That's a big assumption you're making there, buddy.
I don't know how your particular weight is distributed on your particular bicycle or what, but you're spreading dangerously wrong ideas.
If you're going downhill and a child runs out in the street from between cars and you need to stop, and you're a normal person on a normal bike, you need a rear brake, end of story.
If you modulate your front brake to not lock up, that simply means you stop far too slowly, and hit the kid. Even at what seems like otherwise a safe speed, things (like children, or soccer balls) can run out in front of you at the last second and you need to stop suddenly.
You absolutely need a rear brake for safety. Just because you could get by without one in most situations doesn't mean you can get by without one in all situations.
If you're going down a hill and you need to do an emergency stop, the back wheel won't do you any good. The rule of thumb I was taught was that the back wheel will only provide 1G of deceleration, under ideal circumstances. If the road is wet, or there are leaves, assume less.
If anything, the rear brake can be used to slightly pump up the front fork, which allows the front wheel to find its own way through mud/leaves/snow. Basically, apply a touch of rear brake when you go through a slippery curve, squeeze the frame between your thighs, and let the bike find its own path.
If you take into account that during braking, and even more so during an emergency brake, all the inertial weight lies on the front wheel, it makes a lot of sense that the rear brake is so useless.
In France, bikers call their passengers "SDS," which stands for "sac de sable" (sandbag). Very useful to increase grip of the back wheel when accelerating strongly. Not when braking.
While I'm sure you've ridden lots, if you experiment a bit and try different braking techniques you'll learn how much more effective the front brake is. In fact the famous "fear of endo" is actually just a symptom of this: when the bike stops suddenly rather than slowly, some riders find they don't have their COG positioned far enough back to stay over the stopped bike. One never gets that with a rear brake, because as soon as the COG starts moving forward as it must when the bike slows, the rear tire rises off the ground and the rear brake no longer helps. On steeps, I often have my stomach rather than my butt on the saddle, because I want to be able to stop quickly without flipping.
I've actually faced the "child jumping out from behind a parked car" before, and I passed that test. When I jammed hard on both the front and rear, both tires locked, the rear tire swung around the side until even with the front (at that point it was no longer behind the COG so it rotated down instead of up), and I twisted my back foot to unclip and stomp. I looked at her, she looked at me, then she ran on across the street. Glad I wasn't driving a car!
Since you seem to be unable to see that the issue has not been "decided" as you think it is, especially as there are different bicycle types and different body types, I'll leave these quotes here from [1] and [2] so that other people can be safely warned:
"You should always apply the rear brake, and slightly in advance of the front brake, so that a slight skid at the rear will warn you if you get close to the hazard point at which the bike may tip."
"Flat asphalt is one thing, 30 degrees sloped rocky road is another. My hold is that in the second case the back brake is MORE important than the front brake."
"I myself got into the accident once. It happens so fast that you never have time to lean your body backwards and provide more tractions for the rear wheel like other have stated."
"Depending on where your center of mass "hovers" over your bike, you may need a different strategy."
"Having had more than a few over-the-handlebar incidents back in the day, there is no situation in which I would ever even consider using only the front brake again."
"On the road bike you are alot lower and therefore don't go over the front quite as quickly."
"If you learn to move your weight back (ideally behind your saddle) during strong braking then going over the handle bars is nearly impossible (except under very steep hills)." (Note the "steep hills" part, which is my whole point about safety.)
"On mountain bike, the momentum partly transferred to seat and pedal as a result from a more up-right pedalling position. Remember that your body is about 3-5 times the weight of the bicycle, and they are on top of the bike. So the higher you are from the ground, the easier for you to toppled up."
None of those quotes demonstrate anything other than the simple point that someone who has experience in riding a bicycle knows to get their weight back and low so that (per your own quote) it is _nearly impossible_ even on steep hills to endo.
It would be refreshing if you were able to demonstrate a capacity for admitting that perhaps you have something to learn. I would advise taking a mountain bike class and coupling it with something like the U.K.'s Bikeability or the U.S.A.'s League of American Bicyclists equivalent.
I fear, instead, that you will spend your time hectoring internet strangers about the dangers of bicycle riding based on your own incapacities and incapabilities.
You need a rear brake for two reasons. One is redundancy: if the front brake fails, you want another option, even if it's not quite as good. The other is spreading the braking heat over twice as much surface area on long fast descents. (Some tandems have a third brake for that reason.)
The redundancy point is true. The tandem drum brakes are less to do about heat dissipation than stopping your hands cramp up on a long descent. Often you just actuate the rear drum to provide constant drag on a descent.
For anyone interested, specialist tandem outfitters used to shave off the heat dissipation fins on old-style Arai drum brakes. The point of said brakes was not to dissipate heat, but to stop the tandem. It is true that very old tandems with rim brakes had heat-dissipation problems.
Are you claiming that macOS has better vetting of its packages than Linux? And what do you mean by "Linux" anyway? -- lumping RHEL in with ADistroIMadeInMyGarage is a bit odd.
Well, linux doesn't have adhoc package management.
Because there is no standard packaging format between distributions, the best people can do is release a deb that may or may not work on either debian or ubuntu. Or an RPM that may or may not work on RH/Fedora. Or a tar.gz that will contain sometimes source code, sometimes a binary, and if it has source code there's no clear way to compile it, if it has a binary there's no clear way to install it.
So instead, curl sh.
It's pretty ridiculous that it's still a problem, tbh. What we need is somebody with the right political clout at either RH or Debian to sit down with devs of the other, come up with a decently generic solution that fits both systems and a backwards compatibility policy. It doesn't have to be perfect nor the best, it just has to be good enough to support the use cases of most Linux distros.
Once both Debian and Fedora support it, Ubuntu (and its many flavors) and Red Hat will follow. And if it's a generic enough system, with a pluggable-enough backwards compatibility policy, it's not unlikely for it to be adopted in more minor distros. If it's sold correctly, distros will gladly adopt it - we've all been waiting for this a long time.
I guess I do not understand the manner in which you use "ad hoc" to refer to package management.
It seems as though you are now talking about cross-distribution package management. It is further confusing that you are contrasting all "Linux" to the single distribution macOS.
To me the term is "ad hoc" current w.r.t. NixOS , GNU Guix and other purely functional systems, and there the distinction is made between:
1) declarative -- in which a rebuild of the system will ensure the package is present and configured as expected; and
2) ad-hoc -- in which the user can affect all of the system with side effects and rebuilds will not result in the same state.
Why would you want to allow users to randomly and aribitrarily affect all of the system and end up in an unknown state? Isn't that exactly what curling shell scripts achieves? And what method does macOS implement in order to avoid this?
If all you're talking about is cross-distro package management then you and your users can either give up on this and standardize on one OS and just pony up the cash for RedHat (same as you do for macOS) or else start writing Flatpaks.
Hmmm... while agreeing with the sentiment I am unimpressed by the lack of evidence for one of his supporting examples. What stood out for me was this bald assertion with no reference to falsifiable specifics:
"_Not_only_was_it_already_a_much_improved_agreement_from_
the_start_,but it kept being modified from the initial
public version of it to the one that was finally sent to
national parliaments."
Either the writer of this is an expert on the topic, well-known in the field and the weight of this judgement on its own is a valuable primary source; or, the writer is referring to such an analysis conducted by other experts but has not bothered to include a citation/link; or, the writer has their own critique but instead of presenting _that_ has just stated an opinion which they know to be controversial.
All of the above possibilities contribute substantially to the noise around any discussion.
> TTIP was negotiated in secrecy (as all trade agreements are)
That seems like a really steep assumption to try to start a conversation about changing perspectives with time. He opens with a purported tautology about how you must do trade deals, which I feel hurts the argument against moving goalposts - because that seems like the exact kind of sentiment that leads to the behavior in the first place. This has always happened, thus it must always continue to happen is rarely a way to start productive dialog about something.
That's another good example. The original post is actually nearly an example of "How to start a flamewar."
You can even see the discussion of CETA spawning a long, subsidiary thread which distracts from the central thesis which we should be arguing about. (I am not offering an opinion on the content of that discussion.)
The real takeaway should be that if you want to make a point about the topic of discussion you really cannot use real world examples. Nothing is black and white, everything is nuanced, and online someone will argue anything (including the connotations associated with the word "is" in this very thread).
It should be no surprise that if you make a post trying to talk about the meta of controversial topics, that if you start directly citing said topics the discussion ends up being a debate about the controversy rather than the original intent.
The problem is not with the voting system: it's with the fact that most people are vastly under-educated and propagandised -- and that's just the Hacker News population.
Ooooh... I like that! There's bound to be a large body of case law on it. This argument (a) suggests that the person(s) constructing and/or maintaining a machine are culpable
Because the occupants of the cars want to get to any and all places where there are non-occupants of cars. The conflicts are inherent. Car use is fundamentally an irrational application of technology that appeals to the lazy.
1) Journalists communicating with WhatsApp struggle with it and mess up.
Given the confusion around under what circumstances one can communicate securely with WhatsApp ("Is it OK if I have two checkmarks? Is it OK because Facebook would never let a government have access to the RedPhone part?")
2) Activists who use WhatsApp do so relatively sparingly. I have no idea on this one. I hope they're using Signal and/or GPG with all their attendant bother, complexity and confusion though.
3) No other sane person is willing to use WhatsApp by default. Hmmm.. more confusing value judgements. Is someone that uses a communication method open to abuse by corporations and governments "sane"?
4) Dependency struggle. AFAICS no other projects can piggy-back off WhatsApp because it's proprietary and closed. So the user base can't scratch their own itches. OK, so what about Signal? Sounds like the dependency on Google Cloud Messages and Play Services can be hacked around with great difficulty.
I dunno. Fair play to Moxie and Perrin for what they've done, but so far GPG looks like a better bet for actual secure end-to-end communication, using an already existing, widespread distribution mechanism which is widespread and redundant: email.
Reports of GPG's death may have been grossly exaggerated.