chaz72

That's an interesting theory. Do you have data?

Don't have a citation handy but I have read that some banks would authorize cards for Apple Pay without any decent authentication.

So thieves that had stolen credit card numbers elsewhere registered those cards on their Apple Pay devices and then used those to charge them.

The credit card numbers had already been stolen, but Apple Pay was used to buy things on those accounts.

There is not - that I have ever seen - any indication that Apple Pay has been hacked.

The real fight here is not about Apple at all. It's about banks (who want a new secure standard) vs merchants (who want to maintain their tracking abilities and maybe get out from under the 2% fees).

> Until there's a free, easy, maintainable, and actually existent solution to SSL certs, enforcing HTTPS-only is just downright extortion.

True - but the second that solution exists, I can't think of anything that should stick with unsecured HTTP, and this article didn't change my mind. I don't think we need a "ban", though. Just flip the way browsers show secured vs unsecured, instead of the green reassuring lock for https, that becomes the expected default and http gets a scary red plaintext indicator.

The first proposition tests the blackness of ravens. The second proposition tests the non-raven-ness of non-black things. When abbreviated, it sure looks like a paradox.

It's about 99% of "people who have no idea how to install a new browser", so that kind of skews those numbers.

Yes, I think so. I mean, it is ridiculous and horrible, but ... After thinking through it for a few minutes and pairing it with an XSL schema translator, this could enable some integration on systems where there is no code and it's all pure XML data driven.

If they explicitly say they will stop in the release version, I would accept that argument. If not...

Ah, now that is what I was looking for but didn't know how to ask. A few starting points I might trust would go a long way.

For those already using PGP, that sounds great. For me, who is not using PGP, my set of trusted keys is currently empty. So it is unverified.

Which, arguably, might be safer than being overly trusting of my "trusted CAs", which is verified by a flawed system.

I guess I'm still not thrilled wih my options overall, but thank you for your time explaining how to use PGP.

Never mind, I see a higher ranked comment got an answer to this. I see the concept of keys signing keys and gpg --list-sigs. (Still no idea who might be at the end of that chain that I could actually verify though.)

Thanks, I will look into this.

That's very thorough, thank you!

I understand all those things in general, but I don't know the specific mechanism by which my local PGP install recognizes who else trusts this PGP key. I grant you that if the key is protected from MITM then all is well. I just still don't know this part:

What mechanism do I use, I who have no prior encounter with that key and no existing PGP setup or connection to any web, to validate that key?

I'm sure this is just a lack of familiarity with PGPs web of trust implementation, but lacking this info, I too just opted to trust the plain HTTP download (until I switched to Cygwin/OpenSSH to make it a moot point anyway).

I have to ask: how are the PGP keys verified?

Dependencies from other repos. Is there a better way that's the equivalent of a Subversion external?

Oh, no doubt Subversion has its downsides and Mercurial is really good at what it does. I was just musing through my own tradeoffs. It is a very narrow point but one that I hope is in the spirit of the article.

Partial repo checkouts, SVN externals are the two areas where I feel I lost something when "upgrading" to Git. So yes, I quite agree, there are definitely tradeoffs.

If they follow through, we will finally have a mass market PC maker recognize the importance of a clean install. If they follow through completely enough to get Microsoft's "Signature" branding, then I just might have to start recommending them again.

All because they screwed up so colossally that they had to turn it around or see themselves decimated.

Interesting times.

I have been wondering whether to go back to Subversion myself. The distributed option really doesn't apply to me, my minimal branching needs are met by Subversion, and oh my god, git's submodules get confusing.

The developer should absolutely be involved in that discussion, as the person with the best information on the cost of supporting that long tail. If complexity makes the system less reliable for the 98%, supporting the 2% may be a fool's bargain. (If, I say - your mileage depends on your tech and your team.)

Will you have automatic upgrades for the life of the device?

I agree, but I do see one distinction that I find interesting: if someone tries to pick a lock on a county building and they try 44 different lock picks, is that one charge or 44?

Even once is a serious charge, but I'm not sure there were 44 crimes committed.

Or perhaps "well rounded"

Will OpenBSD look to pull from their updated C++ libraries?

A lot of confusion about why this is going on. My take as a very interested user who has been actively tracking down info about this Node's next release and possible fork for some time is this:

Node.js's last supported release uses such an old version of Google's V8 that this V8 version is itself no longer supported. This, in my opinion, is just not good enough. In my personal experience, when a release cycle gets that fucked up there's a reason.

Joyent hasn't shared what the reason actually is for the delay, but so many of the top contributors think they can do better with a fork, and I'm going to give them the benefit of the doubt.

The plan is to do weekly releases, semver, to keep absolutely up to date with Google V8, and incidentally to not let just one interested party dictate their future directions.

It's a good plan and if they follow through, I'm definitely on board.

As a recent convert to Node who switched to it because I thought we'd be closing in on 1.0 this year and instead got ... crickets. For my part, "pulling more regularly from V8" is enough all by itself.

Ah, now that is an interesting belief. Is it based on anything you can share?

I used TypeScript for a project earlier this year. As a C++/C# expert and a JavaScript noob, I found the clarity, the readability of my code to be far superior with TypeScript, well worth the extra tooling.

Then I found that after working that way for a number of months I no longer needed it. I picked up enough JavaScript along the way that I could I drop the training wheels and I am not looking back.

Actually, no, that was just a prediction. I am making an assumption - and maybe not a fair one - that because Google mines user data on the web that they also mine user data on the phone.

Skepticism seems warranted. With Apple, I try to be skeptical, but with Google, I always assume that I am the product until they demonstrate otherwise.

Until Apple promised it so explicitly, I'd have said you might be right. True, Google and Facebook make zillions off of monitoring people for advertisers. That will make it harder for them to follow suit, there will be far more weasel words and such when they try.

I think those of us that are willing to pay the premium for something that promises more have higher expectations. If they are lying, I believe we'll know within the next year or two and we'll get to find out if you're right.

That definitely could imply they have received an NSL. But as a user, when I say "they would leak that they're fighting it", I would consider that completely insufficient. If they are pulling the kind of crap you say they are, then it will come out. Guaranteed. And then nobody, including me, will ever trust them again.

editing my comment since I can't reply to hellbanner: Percentage doesn't matter, it only takes one. One person to destroy a hundred billion dollar company overnight. I am not saying "Tim Cook can not possibly be lying." I am saying "If Tim Cook lied, he just made a hundred billion dollar bet that he can keep a secret." Personally, I doubt he's that dumb.

Then they better have perfect security so there are no leaks proving that, or they're gonna lose their business anyway. I don't buy it, they'd fight that and they'd leak that they're fighting it.