The analogy isn’t 1:1 but I think the core of MS and what he was doing in the cloud division might as well had him an outsider. MS was still highly Windows first all others second under Ballmer. Under Nadella he bet the future of the company on cloud and it’s been the right choice. What if they do the same with a changing of the guard — not immediately but eventually?
> their truths are being overshadowed by those who seek to use these accusations as a way to screw over somebody they didn't like or for attention or even for money.
Wow. Given the well-supported allegations of sexual misconduct, published in reputable newspapers recently, yours is quite the claim. Who is doing this for attention? Do you have any evidence?
> a career death sentence has already been carried out by a virtual lynch mob
Did you read the article you are commenting on?
> "... sources said that the investigation uncovered behaviors by Jurvetson that were unacceptable related to a negative tone toward women entrepreneurs."
So if the article is correct, your claim that there is nothing more than "mere allegations" so far is wrong.
You are very misinformed about Apple Pay, and the poster you are replying to is correct. CC networks pay the Apple Pay surcharge, not customers or vendors. To vendors, Apple Pay looks like a regular NFC transaction, except with a one-time card number, so there is no danger of the kind of hacks that happened to Target, Home Depot, and many other retailers. Apple has nothing at all to do with "reviewing and resolving fraud and other claims." The CC networks still do this.
When I buy a burrito and then look at a receipt (as I always do after buying a burrito) I do not see the visa surcharge, or any others. I see tax but that's it. At the end of the day, the consumer pays, because there is no free lunch, there are no free burritos.
I may have made an incorrect assumption regarding claims handling, though I'm not sure how that translates me to being "very misinformed".
I wasn't speaking only from the vendor perspective (idk what it looks like to them) or the Apple Pay customer's perspective (I'm not one of their customers) but I highly doubt it's worth my time to research to confirm that adding Apple Pay into the mix does not somehow increase the attack surface or how it does not somehow increase the amount of my personal information that is with Apple.
Nearly everything in your original comment is wrong. You say there's a "minor surcharge" but the cost to the vendor is the same as any other credit card. You mention the cost of supporting yet another platform, but the platform is just NFC, there's nothing special needed to support Apple Pay specifically. You say the consumer has their fingerprint tied to payments, but the fingerprint data never leaves the device. You say the attack surface is increased substantially, but Apple Pay is much more secure than using a credit card directly. (Not that consumers need to care, since fraud protection is 100%.) You imply that credit card companies aren't involved in resolving fraudulent Apple Pay transactions, but they are. You close by saying that Apple Pay isn't just a nice frontend for the card companies with better security, but that's precisely what it is.
I personally think this can rightly be described as "very misinformed."
>> there's nothing special needed to support Apple Pay specifically.
Yes, there is. NFC enabled terminals may be the norm at major chain stores but they do not have widespread adoption in smaller retail outlets.
The merchant pays for those terminals and they are not inexpensive. Sometimes $1000 or more. That tradeoff (making it slightly easier for you to pay) just isn't worth it to most merchants right now. As EMV adoption grows and merchants have to update their terminals to support that as well, NFC will grow.
Also, it may seem as if ApplePay is more secure for the banks as it prevents issues with data breaches but to date, it has not prevented any, will continue to only lessen the impact and is absolutely wrought with card fraud as there isn't any validation that you own the card you are loading into ApplePay. Once it's loaded it isn't checked by the merchant (if the merchant even pays attention these days) and is implicitly trusted by the network.
The key word there is "specifically." Apple Pay may require technology that isn't 100% deployed, but it is a generic and standardized technology that long predates Apple Pay, not some new Apple-only technology that the boys in Cupertino came up with and foisted on the world.
I don't understand your security point at all. It hasn't prevented any breaches? How do you know? It doesn't validate cards you enter into Apple Pay? If you possess the card (or can make one from having possession of the card data) then you can already use it fraudulently, loading it into an iPhone is just an extra unnecessary step for the thief. The security advantage is that malicious terminals can't steal card data, and stealing your method of payment doesn't confer the ability to pay. It's not perfect by any means (and again, not something us consumers need to even care about), merely better than a regular plastic card.
It took the UK a few years since contactless cards were launched around 2010. Everyone already had chip+pin terminals, and at first it was mostly coffee shops in London, but now many merchants have upgraded to contactless ones. It's not just national chains, but local shops too. It's much faster paying by contactless in a busy pub than paying cash.
It's possible there's pressure/support from Visa and MasterCard for small, local retailers to accept contactless payments. It's part of their advertising that you can buy a newspaper using the system, and most newsagents are local, independent shops.
A basic chip+pin (not contactless) terminal is available for £100 (or £3/month), I can't find a price for a contactless one.
How can it be harder to climb Amazon's corporate ladder unless they have less management or do more outside hiring at a senior level than other companies? Somebody has to get promoted to fill the positions, right?
What bothers me isn't the name, but how the syntax looks like nothing else in HTML. At the time the idea was floated, there were a few alternatives talked about that mimicked the <video> and <audio> tags that made way more sense, and opened up for adding webp alternatives with png/jpeg fallbacks etc. It's a real shame they NIH'ed those.
That part in the article felt strained: Mat was clearly trying extremely hard not to be rude while showing how much cleaner <picture> is. Hopefully this is an opening salvo rather than the end of the discussion…
The problem with picture is that it doesn't poly fill nicely. You can add srcset attributes and it will still work on IE6. I have been using srcset for over a year, and there is is only a minor issue of retina MBPs double downloading. There is no problem with high res tablets.
I don't remember any issues polyfilling video, does anything make picture different? This is one of those things one person has to write once and then everyone can reuse it.
A polyfill of <picture> much more expensive. First you have to shiv IE to accept it as a DOM node. Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>. Polyfilling "srcset" is trivial as in:
if browser is modern and high-res,
replace the value of src.
else
pass
Doing a flash video polyfill of a video tag is okay because there is probably only one video on the page. Polyfilling <picture> would produce some seriously janky page rendering, and would be a pain in the ass to maintain.
In the proposal I saw, browsers that supported <picture> would ignore <img> tags inside a <picture>, meaning for anyone who isn't strict about pure semantic HTML, they could just stick an img in there for older browsers.
> First you have to shiv IE to accept it as a DOM node
I find this an increasingly weak argument as it's applying to <10% of the market and falling fairly rapidly ahead of the 2014 Windows XP end of life and is true of everything else in the HTML5 spec.
> Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>.
This is a reasonable complaint - I'm not sure I'd consider it a big deal since the work of manipulating the DOM is a lot faster than doing anything like downloading an image or rendering it but for anyone trying to do a wall of images it'd be worth benchmarking at the very least.
(<noscript> should keep browsers from loading the image tag, so you could do things like have JavaScript evaluate your image candidates and generate an img accordingly)
I'd prefer an extra tag during the migration stage to make the long-term goal more readable, particularly if we start wanting to extend it to do things like offer different image formats rather than just resolutions.
In the proposal I saw, browsers that supported <picture> would ignore <img> tags inside a <picture>, meaning you could use it as a fallback for legacy browsers.
It's a page of 9 short comments, but 8/9 are are elided after the first few words. Is the new way of talking to each other sentences where you can't see the end?
