Precisely this. The title of this article should probably be renamed because it's looking at specific examples where the whole process (ie login + registration flows) hasn't been implemented properly.
Not sure if this is still the case, but Marcos from Mozilla did a talk on this at CampJS earlier this year. Apparently Chrome will send data about the items purchased to Google, even if you’re using a payment provider completely unrelated to Google.
Unlike Chrome, Firefox will apparently not send data about what you purchase back to Mozilla.
> Unlike Chrome, Firefox will apparently not send data about what you purchase back to Mozilla.
It sounds like something has been lost in translation. If not, Marcos is conflating two very different things.
If you use Payment Request in Chrome with Google Wallet or Android Pay then yes, Google is going to have a description of what you bought and where you bought it. But you used their payment service. This is no different to what PayPal or a dozen other payment services are doing.
If you use Payment Request in Chrome as a replacement for auto-fill - that is, you're just using it with regular card numbers, or with another non-Google payment instrument then nothing is being sent back to Google. Go check the source code, it's all implemented in Chromium (indeed, other Chrome based browsers that integrated Payment Request like Samsung's own mobile browser or AliPay are using Google's implementation).
The reason that the standard asks for a description of what you bought is that it's useful to display to the user in a standardized way as part of the payment process so you can reconfirm exactly what it is you're paying for.
I sat on the Payment Request Working Group until about three months ago and I didn't hear any of these concerns from Mozilla then. I don't really know what Marcos has been saying, and since the talk itself isn't online I'm going to assume he's been mis-quoted.
> If you use Payment Request in Chrome with Google Wallet or Android Pay then yes, Google is going to have a description of what you bought and where you bought it. But you used their payment service. This is no different to what PayPal or a dozen other payment services are doing.
Importantly, it _is_ different than what Apple Pay does.
Don't think there's recordings of CampJS for this year, but on the schedule [1] there's a talk about it listed by Marcos Caceres. You could probably ask the guy on Twitter (@marcosc).
Ahh, that completely changes the meaning. It's basically just like credit card processing in that case, but just for Android Pay (and probably Apple pay if/when they adopt the API). The transaction description/line item thing makes a lot of sense from a user perspective (granted, I am not, and do not intend on becoming, an Android Pay or Apple Pay user).
Yeah, seems to be limited to Google’s own payment services.
Just so you know, Apple doesn’t see nor store the item/s you purchase via Apple Pay, so if Apple Pay is accepted through this payment API, I think it’s unlikely to send purchase information directly to Apple.
Agreed. I'd also like to see the source for this, as I can't find it mentioned anywhere on the Chrome sites about PaymentRequest or any of the top sites talking about Chrome Payment Request.
> its the utter lack of carring for the osx platform.
This is short sided. $AAPL cash cow is obviously mobile, however I don't agree that they don't care about desktop. I assume your referring to the blog outrage about the new MacBook Pros? News flash, the bloggers who were complaining the loudest and making the biggest noise on HN and in the news are a small minority. Notice how you don't see daily stories bashing Apple as much now.
I hopped on the OS X train when Apple first released the x86 MacBook. OS X 10.4 was a major improvement over 10.3, Windows and Linux. Leopard and Snow Leopard brought even more improvements and features. Things started stagnating after Lion.
Today's OS X development is pretty lame by those standards.
macOS is now on a yearly release schedule, so it is logical that the deltas are smaller. If you look at the typical OS X release timeframe of yesteryear, there are quite some great improvements changes:
- Introduction of an OS-level hypervisor (Hypervisor.framework).
- Much better security and resistance against rootkits (SIP).
- A new filesystem (APFS).
- The introduction of a far more modern programming language for development (Swift).
- A new graphics API (Metal).
Sure, some coincide with features added to iOS, but I see that as a strength. There are also user-visible changes, but I care less about them. To me, the WIMP paradigm seems to have reached a local optimum and I don't think anyone is helped by Windows 8 or GNOME 3.0-like experiments.
In my experience, OS X has gotten strictly worse with every release since Snow Leopard. Spaces crippled for no reason, fullscreen apps forced to a separate space for no reason, the already-large brightness/volume popups made nearly opaque (and not adjustable without major hacks), and everything's slower (the WindowServer process now spikes to 50%+ CPU usage for long periods, and no one can figure out why). In return, there hasn't been a single new feature that I care about. I only upgraded because more and more new software was requiring recent versions, and I'm kinda thinking it wasn't worth it.
The stuff you list is nice if you're developing software for the Mac, I suppose. I can't get too excited about the prospect of better software when the underlying OS is getting steadily worse.
you have to admit those are things with very minor effect on users. Sure, it will be nice to use APFS in the future, but it doesn't bring anything new.
OSX releases before Lion had much more innovative stuff, e.g.
The early releases of OS X were far more primitive, so more work needed to be done on the basic building blocks (e.g. CoreImage or CoreAudio). Besides that, half of these features I have never used:
- Dashboard: never used it. Fiddled for 10 minutes and decided it's not useful.
- Automator: maybe some Alfred workflows that I use, use automator, but I never used it directly. I also don't think anyone outside power users write automator scripts. And these are the same people that can benefit from APFS or Hypervisor.framework.
- Spaces: gone. I am still sour about this though ;).
- Time machine: not that great in practice. Especially with a Time Capsule/Airport often results in backup sets that are broken.
- Cover flow: never used it, not saw the point.
- Boot camp. Never used it.
So, I and most Mac users that I know don't use half of these features. I also know quite many non-techie users that don't even know that Spotlight exists (they launch applications via the Dock and use Finder).
But most use them in some way or another which is why they are still around.
Also many people who use the mac are people who use it to develop other things like web services and ios apps. They use it as an actual actual productivity platform and create much of the value of the iPhone ecosystem.
Apple is basically lining up for it's own demise in the long run, the more they tighten the rope around the developers and kill much any of the thinking which should be helping them build the fundation of the future.
But perhaps the mac have just become a nuisance which needs to die. In that case they are doing a great job.
Security is a trade-off, not a slider to maximize. A machine with no network connection and no ability to install new software would be ultimately secure, but not much use. Caring about your users means optimizing the ratio of security to usability.
I agree - they're definitely putting the customer's security first. If people want to use an open environment, the web browser is always available on iOS anyway. Apple are completely within their rights to restrict their application platform.
>Apple are completely within their rights to restrict their application platform.
it is like to say that GM is completely withing their rights to restrict where you can drive your GM car. Mind you, that is coming in pretty near future too - giving all the computerization/connectivity/self-driving of the cars which would make the cars into GM's "application platform" with DMCA protecting such a platform too like it protects Apple/Google/FB/etc...
Not the same thing. It's like GM telling aftermarket accessories manufacturers that if they want to sell their products through GM dealers that they must meet GM standards. The inability to use Rollout has no real impact on consumers.. except by improving safety.
>if they want to sell their products through GM dealers that they must meet GM standards.
i wonder whether you're intentionally skipped that part or just don't know that in case of non-jailbroken iPhone the "GM dealers" is the only way to get "aftermarket accessories". There is no "if they want to sell their products through", instead there is "if they want to sell their products at all".
At this moment Apple is effectively banning web browsers except their own safari. The other browsers you see on iOS are just a wrapper over the native webkit view.
Probably a controversial opinion, but seeing how Safari is the only browser behaving correctly on macOS (performance- and battery-wise), I'd assume only Apple has the motivation to make a correct browser for iOS.
Imagine the kerfuffle if Google had Chrome on iOS. 2% of "PC" users complain of Chrome hitting their battery hard on macOS. iOS has a much bigger market share.
Competition is healthy, I agree. But sometimes the best interest of the vendor and the users don't align, and I'm more confident Apple is prioritizing battery life and performance over other things, while Google will prioritize those other things (like ads and data collection). I can't imagine them allowing adblockers on iOS (exactly as they don't on Android, afaik)
why not let the consumer decide their browser of choice? Apple isn't prevented from creating battery efficient code by allowing others to write a browser.
From a user point of view, I see many differences and even paradigm shifts across webkit-based browsers on all platforms. When you call a browser 'just a wrapper over webkit view', I don't even know from where to begin. Specific engine is the last thing to consider today.
This might sound a bit counter-intuitive, but learning how to break things has helped me the most in learning how to create things. I'm not at an absolute expert level in the IT security field, but it's the thought process that has helped me build a deeper understanding of how things are developed. From this, I have learnt and continue to learn how to think critically about whether a particular design for a piece of software I'm trying to break is good or bad, and also think about what I would have done had I been a developer.
I guess in a sense, it's me asking myself the question of how I could personally design quality software at all levels. Getting into the nitty gritty details from learning how to break things has really helped me learn more about development at all levels. From the low level, where, say, Java might have a function that could be used inappropriately - questioning why they were designed that way. To libraries that have issues - questioning why the developer used this library. To the high-level, the overall pieces of the system - questioning if they interact with each other in a logical way. Then there's also the user interface and experience aspect.
So, understanding the reasoning behind choices and why things are the way they are (from the level of the C programming language, to the libraries you use, to how the users expect to interact with it, and what other developers would expect if you want them to contribute to it) is the one thing that has helped me become a better developer. It just so happens that in IT security, you tend to ask yourself and the developers you're working with these exact questions.
