Has Apple ever created a best-in-class iOS app that works OUTSIDE the walled garden?

[Arlen Holder]

Has Apple ever created a best-in-class iOS app that works OUTSIDE the
walled garden?

In a discussion about Apple Maps, it was remarked by sms that:
"Apple seems to be committed to making Apple Maps
as good or better than Google maps."

To which Chris responded:
"They were saying that when they first launched Apple Maps
six years and still haven't got even close."

If Apple has never produced a single best-in-class iOS app that works
outside the walled garden, then Apple Maps likely wouldn't tip the scale in
their favor, particularly since they're going against Google which does
make best-in-class products which work universally around the world.

Hence the basic question, mostly for the ardent Apple lovers to answer:

Has Apple ever created any best-in-class iOS app that actually works well
OUTSIDE the walled garden?

--
(And nospam, Lewis, BK@OnRamp, Jolly Roger, etc., just saying "yes" without
backing it up with facts is "just guessing" where your combined record is
worse than that of the monkey.)

[Alan Browne]

On 2018-07-07 08:19, Arlen Holder wrote:
> Has Apple ever created a best-in-class iOS app that works OUTSIDE the
> walled garden?
>
> In a discussion about Apple Maps, it was remarked by sms that:
> "Apple seems to be committed to making Apple Maps
> as good or better than Google maps."
>
> To which Chris responded:
> "They were saying that when they first launched Apple Maps
> six years and still haven't got even close."
>
> If Apple has never produced a single best-in-class iOS app that works
> outside the walled garden, then Apple Maps likely wouldn't tip the scale in
> their favor, particularly since they're going against Google which does
> make best-in-class products which work universally around the world.
>
> Hence the basic question, mostly for the ardent Apple lovers to answer:
>
> Has Apple ever created any best-in-class iOS app that actually works well
> OUTSIDE the walled garden?

I really shouldn't reply to this obvious, poor quality troll post, but
let's take a small shot...

I don't think of iOS in terms of apps as much as in terms of integration
- esp with Mac OS. Most esp. Notes/Messages/Remiders/Calendar/Contacts
integration via iCloud is seamless. The ability to do Messages on my
Macs (whether SMS or Apple Message) seamlessly is great as is the
ability to pick up a phone call from my Macs as I usually don't have my
phone "on me" all of the time. I use notes extensively for short term
information (ie: going to the store I just dump a note on my Mac and
there it is seamlessly on my phone or iPad).

While you can do these things in varying degrees on Android, the base OS
integration between iOS/Mac is seamless and supremely well integrated.
It's hodgepodge on Android because this sort of integration is not baked
into the OS at the base level and of course the hidden glue of iCloud is
missing. It's certainly absent in the majority Windows/Android domain.

Maps remains a sub-par application and updates to its "satellite" photo
base are woefully late. But I don't care because Google Maps more than
meets my needs.

Apple's goal shouldn't even be to provide the best apps IMO. Their goal
should be to provide an OS and development environment that allows
developers to do so while taking advantage of the integration
environment. That is more valuable by far than Apple coming up with any
"best-in-class" attempt they might make. That would be a waste of
resources as well as counter productive when there are so many app
makers out there who specialize in a particular area.

Anyway, do continue with your feeble trolling.

--
"2/3 of Donald Trump's wives were immigrants. Proof that we
need immigrants to do jobs that most Americans wouldn't do."
- unknown protester

[Arlen Holder]

On 7 Jul 2018 07:32:12 GMT, Alan Browne wrote:

> I really shouldn't reply to this obvious, poor quality troll post, but
> let's take a small shot...

I appreciate that you gave a new perspective on the problem set!

> I don't think of iOS in terms of apps as much as in terms of integration
> - esp with Mac OS.

Agreed. I ask *everyone* I meet why they like iOS, and most of them tell me
similar things as you just said above. (Remember, I buy iOS devices all the
time - but I generally give them out as gifts.)

> Most esp. Notes/Messages/Remiders/Calendar/Contacts
> integration via iCloud is seamless.

Agreed. All the users, bar none, that I ask why they like iOS, tell me that
they feel the integration of certain critical apps, is fantastic, within
the confines of what they need them to do.

I think that's a key advantage of the apps that Apple creates, which is
that they work very well within the guidelines proposed by Apple, which, we
all know, fits the needs of most people who are either on an all-Apple
network, or who interact with other Apple users.

> The ability to do Messages on my
> Macs (whether SMS or Apple Message) seamlessly is great as is the
> ability to pick up a phone call from my Macs as I usually don't have my
> phone "on me" all of the time.

This is a nice integration, I agree. I don't have that particular need, so
I haven't tested it on iOS nor on Android - but it seems to be generally
useful indeed. Thanks for noting that feature.

> I use notes extensively for short term
> information (ie: going to the store I just dump a note on my Mac and
> there it is seamlessly on my phone or iPad).

Agreed that this is a nice integration with the Mac, which, I think is your
main point, which is that Apple makes best-in-class apps that integrate
well with other Apple products.

This is a critically important "feature" of the Apple product base.

> While you can do these things in varying degrees on Android, the base OS
> integration between iOS/Mac is seamless and supremely well integrated.

I don't disagree that you can probably do it all on platforms not supported
by Apple - but I do get your main point - which is that, for the platforms
supported by Apple (which are those that matter to you), the best-in-class
feature that Apple builds well is the seamless (i.e., almost automatic)
integration to other Apple products.

This is a key differientator for Apple products, I agree.

> It's hodgepodge on Android because this sort of integration is not baked
> into the OS at the base level and of course the hidden glue of iCloud is
> missing. It's certainly absent in the majority Windows/Android domain.

I agree that it's a "hodgepodge" on Android with respect to app integration
with the other major consumer platforms, iOS, Windows, & Linux (all of
which I use daily).

While the "hidden glue" is the iCloud, one issue is that you have to rent
your data back from Apple, if you're not careful to keep below the rather
puny 5GB limits.

NOTE: I'm not sure if the free iCloud is still puny as I turn it off on all
iOS devices, because to stay within the 5GB limit on a 128GB iPad, is
possible, but not without some effort and still archive all the useful
data. I prefer to just slide all my iOS data to and from my desktop at
will, which I could automatic, but haven't bothered yet).

> Maps remains a sub-par application and updates to its "satellite" photo
> base are woefully late. But I don't care because Google Maps more than
> meets my needs.

I appreciate that you're being sensible about the Apple Map app quality,
where I always respond to all posts in the manner and intent I perceived
them to have been made.

While I hate Google's spying propensities, I certainly have to admit that
Google Maps killed everything before them (e.g., Garmin Maps, which I had
used extensively), such that Apple will have an extremely difficult time
comopeting with Google.

Personally, I don't think Apple can do it, for two reasons:
1. Google is well funded so they can keep ahead of Apple, and,
2. Apple has a history of overpromising - which I think they're doing here.

What actually prompted this philosophical/technical thread was that Apple
recently made the news in promising a vastly improved map product, where
the question naturally arose of whether Apple ever created a best-in-class
product.

You've explained that with respect to *seamless integration* inside a
network of Apple products and users, they *do* create a best-in-class
solution, which I don't disagree with.

Of course, we have to counter that argument with the fact that there are
still a *lot* of areas where Apple integration is NOT seamless (e.g., the
lack of ability to set defaults and to change menus and homescreen
organization) - so the real answer to the question isn't absolute.

Apple creates *some* apps that are best-in-class with respect to seamless
integration to other Apple products and users (such as the apps you've
mentioned).

> Apple's goal shouldn't even be to provide the best apps IMO.

This is a critical observation on your part, which I admire.

I agree with you that Apple will likely fail if they attempt to make a
series of best-in-class applications in terms of flexibility and power,
since, as we all know, Apple restricts what apps can do (for a variety of
assumed but never really known reasons).

Why does Apple restrict what apps can do?

That's a mystery to me - simply because there are so many things that iOS
apps can't do that there can't be a single reason for the functionality
restrictions.

As an example, nospam is proud of stating that an automatic call recorder
or torrent app is "breaking the law", but certainly being able to organize
your home screen any way you like doesn't break the law.

Snit is fond of claiming that iOS can graph wifi signal strength over time
for all access points, where the fact iOS can't do that might be, perhaps,
a "security" concern that apps can grab that information???

Jolly Roger is fond of saying you can jailbreak iOS to add desired
functionality, where the fact that iOS doesn't allow other app repositories
"may" be both a profit concern, and a reliability concern.

While we can "guess" why Apple restricts what those apps can do, it's hard
to figure out, for example, why Apple won't allow the user to load any
desired app launcher - so that they can get the kind of organizational
functionality that you see in this screenshot below...where I can rename
any app to fit the task, I can put the icon on any grid, I can hid or show
any app any number of times in any number of task-based folders, etc.
<http://img4.imagetitan.com/img.php?image=18_android_apk022.jpg>

The enigma, to me, is what valid rationale can Apple possibly have for not
allowing the users to organize their desktop as they see fit?

> Their goal
> should be to provide an OS and development environment that allows
> developers to do so while taking advantage of the integration
> environment.

This is a very astute point that you make, with respect to the original
question, which is that Apple doesn't have to create the best-in-class
apps, when the *developers* are the ones who are supposed to do that for
them.

> That is more valuable by far than Apple coming up with any
> "best-in-class" attempt they might make. That would be a waste of
> resources as well as counter productive when there are so many app
> makers out there who specialize in a particular area.

I can't disagree, but then we have to wonder what Apple's strategy is when
they *attempt* to make a best-in-class mapping app.

Maybe if someone else other than Google had made the best mapping app, then
maybe Apple wouldn't be sinking a lot of money into Apple Maps?

Dunno. But it's a good point that Apple doesn't have to make the
best-in-class app if developers create a best-in-class app for them.

> Anyway, do continue with your feeble trolling.

It's a serious question, where I always respond in like manner and tone to
the perceived intent and quality of the post I'm responding to.

I made the observation that Apple doesn't appear to have made any
best-in-class apps by way of functionality, where you brought up the
perfectly valid counterarguments of:
a. Apple may have some best-in-class integration into their ecosystem, &,
b. Third-party developers can be entrusted to make best-in-class apps.

[sms]

On 7/7/2018 5:19 AM, Arlen Holder wrote:

<snip>

> If Apple has never produced a single best-in-class iOS app that works
> outside the walled garden, then Apple Maps likely wouldn't tip the scale in
> their favor, particularly since they're going against Google which does
> make best-in-class products which work universally around the world.

Apple Music. Some people say that it's better than Spotify because
you're able to store your own music in a "digital locker." Spotify has
advantages as well, so I'd call it a tie for best in class. And BTW,
Google Music isn't even in the same class as Spotify or Apple Music so
don't claim that Google is best-in-class" for everything.

For revenue producing apps like Apple Music, where there were
alternatives if they didn't offer it on Android, it made sense to sell
it to as many people as possible.

Perhaps Apple Pay should be offered on other platforms as well. One
place I was at earlier this week only accepts Apple Pay for payment, no
cash or credit cards. Since Apple gets a cut of every Apple Pay
transaction, the revenue would be significant, as long as it didn't
affect sales of iPhones.

For Apple Maps there might be an upside if it's significantly better
than Google Maps, given the advertising revenue, but that'll be a tough
sell to get people to give up something that they're used to. I'd love
to see a navigation app combined with something like Strava.

[nospam]

In article <pib776$a3a$1...@dont-email.me>, sms

<scharf...@geemail.com> wrote:

>
> Perhaps Apple Pay should be offered on other platforms as well.

there's no point in that, given that apple pay has 90% of mobile
transactions.

<https://techcrunch.com/2017/10/23/apple-pay-now-in-20-markets-nabs-90-o
f-all-contactless-transactions-where-active/>
The advances point to how Apple wants to steal a march when it comes
to using phones as a proxy for a card or cash, and there is some
anecdotal evidence that it零 working: merchants and others who have
partnered with Apple say that Apple Pay is accounting for 90 percent
of all mobile contactless transactions globally in markets where it零
available.

> One
> place I was at earlier this week only accepts Apple Pay for payment, no
> cash or credit cards.

actually, they *are* accepting credit cards, via apple pay, which uses
industry standard contactless emv protocols.

they would had to have gone out of their way to block everything else.

> Since Apple gets a cut of every Apple Pay
> transaction, the revenue would be significant, as long as it didn't
> affect sales of iPhones.

see above. it ain't worth the bother.

[Arlen Holder]

In response to the following from sms:

> Apple Music. Some people say that it's better than Spotify because
> you're able to store your own music in a "digital locker."

Hi sms,

Tbanks for that purposefully helpful response, where the goal is to come to
some sort of consensus as to what iOS apps Apple produces that are best in
class.

While I don't stream music, it would seem that your suggestion of Apple
Music is a good contender, in that it may very well be a best-in-class app
from Apple if there are no clear contenders for the music-streaming genre.

Looking to see how it's reviewed, Wikipedia doesn't give it high praise:
<https://en.wikipedia.org/wiki/Apple_Music>
"The original iOS version of Apple Music received mixed reviews, with
criticism directed towards a user interface deemed "not intuitive" and a
"mess". It received praise for playlist curation. ... Apple Music's use of
iCloud for a technology that attempts to match uploaded songs to those
found on the service caused significant issues for some users, with
duplicate songs, missing tracks, and synchronization problems, to which
Apple offered no comment or acknowledgement. It also received criticism for
reportedly deleting users' local music ..."

This has a list of the common music-streaming contenders:
<https://en.wikipedia.org/wiki/Comparison_of_on-demand_music_streaming_services>

It's hard to compare the streaming music from that chart, but, for example,
it's glaringly obvious that "soundcloud" has far more than twice as many
tracks and users as does Apple Music - but everything depends on the metric
used to compare services (e.g., "stingray" has 8 times as many tracks as
does Apple Music).

I'll wait to see if others concur that, for streaming music, Apple Music is
clearly the best in class (as all would acknowledge for Google Maps, by way
of comparison of how to assess best in class tools).

> Spotify has
> advantages as well, so I'd call it a tie for best in class. And BTW,
> Google Music isn't even in the same class as Spotify or Apple Music so
> don't claim that Google is best-in-class" for everything.

Don't worry. I'm eminantly reasonable.
Almost no company is best in class for more than just a couple of products,
if even that.

The question you bring up is what's the best-in-class music-streaming
service, where it seems reasonable to put Apple Music on that list - but -
the one wikipedia article I read doesn't seem to concur that it's best in
class (at least not conclusively like Google Maps is).

> For revenue producing apps like Apple Music, where there were
> alternatives if they didn't offer it on Android, it made sense to sell
> it to as many people as possible.

For me, best-in-class apps are like New Pipe where nothing even comes close
to the price:performance metric, where, for example, for free, you can
download any music that is on YouTube and play it in any playlist you like.

It can also stream anything that is on Google, if streaming is your
schtick. And it replaces YouTube Red, which costs money besides. It's also
constantly updated, and does almost everything you need it to do. All for
free.

That's an example of what I consider a best-in-class product, which is a
soft assessment of price to performance.

> Perhaps Apple Pay should be offered on other platforms as well. One
> place I was at earlier this week only accepts Apple Pay for payment, no
> cash or credit cards. Since Apple gets a cut of every Apple Pay
> transaction, the revenue would be significant, as long as it didn't
> affect sales of iPhones.

Thanks for that suggestion as Apple Pay does seem to be a best-in-class
product, given that retailer acceptance is a critical feature of an
electronic payment system.

> For Apple Maps there might be an upside if it's significantly better
> than Google Maps, given the advertising revenue, but that'll be a tough
> sell to get people to give up something that they're used to. I'd love
> to see a navigation app combined with something like Strava.

I don't know if Google Maps does "tracking" like Strava does, and I don't
know if it can upload to the net like Strava does, but I think I get your
point that Strava is optimized as a best-in-class product for the likes of
cyclists and runners.

Overall, you brought up two contenders for best-in-class Apple products:
1. Apple Music streaming
2. Apple Pay electronic payment

As you're aware, I'd never use either one (nor their competitors), so,
we'll have to see wht others think of these two as potential best-in-class
Apple products.

[Alan Browne]

On 2018-07-13 18:31, nospam wrote:
> In article <pib776$a3a$1...@dont-email.me>, sms
> <scharf...@geemail.com> wrote:
>
>>
>> Perhaps Apple Pay should be offered on other platforms as well.
>
> there's no point in that, given that apple pay has 90% of mobile
> transactions.
>
> <https://techcrunch.com/2017/10/23/apple-pay-now-in-20-markets-nabs-90-o
> f-all-contactless-transactions-where-active/>
> The advances point to how Apple wants to steal a march when it comes
> to using phones as a proxy for a card or cash, and there is some

> anecdotal evidence that it¹s working: merchants and others who have

> partnered with Apple say that Apple Pay is accounting for 90 percent

> of all mobile contactless transactions globally in markets where it¹s
> available.

Which means it would be far more if made available on Android since
there are far more Android smartphones out there. One source puts it at
about 86% Android to 13% iOS (worldwide). So Apple's "influence" would
be much larger if they deployed Apple Pay to Android.

To be sure the article above points out deployment in higher value
markets, so that skews any attempt to guesstimate the value of including
Android.

Not that merchants want it that badly since (per my friend) he's getting
a hit of 5 cents per Apple Pay transaction on top of the CC/DB
transaction fees. He'd rather people simply tap-to-pay with their card
as they've been doing since long before Apple Pay came along.

For him it's no biggie as it's a small percentage of all transactions
and thence a small fraction of a percent of his average transaction
value. For merchants with smaller average transaction value, it becomes
another "rent" over income.

Most of his card transactions are tap-to-pay or chip'd cards - way more
than PayPass.

[sms]

On 7/14/2018 2:08 AM, Arlen Holder wrote:

<snip>

> Overall, you brought up two contenders for best-in-class Apple products:
> 1. Apple Music streaming

https://www.digitaltrends.com/music/apple-music-vs-spotify/

As much as you hate iTunes, being able to have a single front end for
streaming and stored music is a good feature.

> 2. Apple Pay electronic payment

Offering Apple Pay on Android would cause a big increase in mobile
payments, of which Apple gets a small cut.

The market share of Google Pay is small. A year ago it was pegged at 10%
but by this time it's probably 15-20%. While Android users represent the
vast majority of smart phone users worldwide they represent a
disproportionately very small percentage of mobile payment users--they
are simply using other forms of payment. Google Pay is a flop for
whatever reason, Android users don’t want to use it. Maybe Android users
don't trust the security of Google Pay, given the poor record of Google
in regards to malware on Android OS.

Apple is doing a much better job or marketing Apple Pay, while Google
just seemed to do it to copy Apple. A couple of months ago I was in
downtown Palo Alto and merchants were offering big discounts to Apple
Pay users. Samsung actually has the best mobile payment solution,
accepted at far more merchants than Apple Pay or Google Pay, but it's
limited to Samsung phones. Earlier this week I was somewhere where the
cafe ONLY accepts Apple Pay, you cannot pay with cash or a credit card,
but let's just say it's a safe bet that no one that works in that
incredible building is using Android.

> As you're aware, I'd never use either one (nor their competitors), so,
> we'll have to see wht others think of these two as potential best-in-class
> Apple products.

The family plans for Apple Music and Spotify are pretty good deals,
though I don't have unlimited data so I probably wouldn't sign up at
this point. Using mobile payments is something that I might do in the
future but since so few places take mobile payments of any kind I still
have to carry around some credit cards anyway, eliminating any
convenience factor.

[sms]

On 7/14/2018 8:05 AM, Alan Browne wrote:

<snip>

> Which means it would be far more if made available on Android since
> there are far more Android smartphones out there.  One source puts it at
> about 86% Android to 13% iOS (worldwide).  So Apple's "influence" would
> be much larger if they deployed Apple Pay to Android.

Exactly. Do they want that market share of mobile payments or is it
better to maintain the position that if someone wants Apple Pay then
they have to buy an iPhone? Both positions have valid points. With Apple
Music they decided on putting it on other platforms. We'll see with
Apple Maps and Apple Pay. Definitely their are trade-offs.

Speaking only for myself.

[Jolly Roger]

On 2018-07-14, sms <scharf...@geemail.com> wrote:
> On 7/14/2018 8:05 AM, Alan Browne wrote:
>
><snip>
>
>> Which means it would be far more if made available on Android since
>> there are far more Android smartphones out there.  One source puts it
>> at about 86% Android to 13% iOS (worldwide).  So Apple's "influence"
>> would be much larger if they deployed Apple Pay to Android.
>
> Exactly. Do they want that market share

Meh. Apple doesn't crave market share like a drug addict. There are
other more important priorities. When will people get that through their
heads?


--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[nospam]

In article <LZOdnWvhsvKhjNfG...@giganews.com>, Alan Browne

<bitb...@blackhole.com> wrote:

> >> Perhaps Apple Pay should be offered on other platforms as well.
> >
> > there's no point in that, given that apple pay has 90% of mobile
> > transactions.
> >
> > <https://techcrunch.com/2017/10/23/apple-pay-now-in-20-markets-nabs-90-o
> > f-all-contactless-transactions-where-active/>
> > The advances point to how Apple wants to steal a march when it comes
> > to using phones as a proxy for a card or cash, and there is some

> > anecdotal evidence that it1s working: merchants and others who have

> > partnered with Apple say that Apple Pay is accounting for 90 percent

> > of all mobile contactless transactions globally in markets where it1s

> > available.
>
> Which means it would be far more if made available on Android since
> there are far more Android smartphones out there.

nearly all android phones lack the necessary hardware to support apple
pay (secure enclave), and that's assuming apple would even have an
interest in doing so, which they do not. there is no point in it. none
whatsoever.

> One source puts it at
> about 86% Android to 13% iOS (worldwide). So Apple's "influence" would
> be much larger if they deployed Apple Pay to Android.

yet another market share fallacy.

most of those android phones are low end devices which do not even have
nfc, let alone a secure enclave.

again, apple already has 90% mobile payment usage. the *most* they
could gain is 10%, so it's not worth the effort.

> To be sure the article above points out deployment in higher value
> markets, so that skews any attempt to guesstimate the value of including
> Android.

it doesn't skew anything. 90% of mobile payments are via apple pay.

> Not that merchants want it that badly since (per my friend) he's getting
> a hit of 5 cents per Apple Pay transaction on top of the CC/DB
> transaction fees.

bullshit.

<https://www.cnet.com/news/apple-pay-to-generate-fees-from-banks-not-mer
chants-report-says/>
Apple has already confirmed that it won't charge merchants or
consumers for card transactions, yet it's unclear how much in fees
the company can generate from banks.

<https://support.apple.com/en-us/ht204274>
Are there additional fees to accept Apple Pay?
No. Apple doesn't charge any additional fees.

the *bank* pays a small fee to apple, which is taken out of the normal
transaction fee they would have received with a normal transaction, and
since fraud is effectively eliminated, they come out ahead.

and for what it's worth, a chinese restaurant near me pushes customers
to pay *with* apple pay because he claims he pays a *lower* transaction
fee when apple pay is used versus swipe/dip/tap and even google pay.
i'm not entirely convinced, but he is very insistent that's the case.

> He'd rather people simply tap-to-pay with their card
> as they've been doing since long before Apple Pay came along.

up until he gets hit with fraudulent charges. then he'll change his
tune *real* fast.

tapping a stolen card is easy.
using apple pay with a stolen device is for all intents, not possible.

[nospam]

In article <pid4bv$kd4$1...@dont-email.me>, sms

<scharf...@geemail.com> wrote:

>
> > 2. Apple Pay electronic payment
>
> Offering Apple Pay on Android would cause a big increase in mobile
> payments, of which Apple gets a small cut.

apple already has 90% of mobile payments (which you confirm below), so
no, not a 'big increase'.

that also ignores the fact that most android phones can't support apple
pay even if apple wanted to bother doing it.

> The market share of Google Pay is small. A year ago it was pegged at 10%
> but by this time it's probably 15-20%. While Android users represent the
> vast majority of smart phone users worldwide they represent a
> disproportionately very small percentage of mobile payment users--they
> are simply using other forms of payment. Google Pay is a flop for

> whatever reason, Android users donšt want to use it. Maybe Android users

> don't trust the security of Google Pay, given the poor record of Google
> in regards to malware on Android OS.

there are a lot of reasons, but at the end of the day, almost all
mobile transactions are via apple pay, and that's *without* having an
android version of it.

[nospam]

In article <fqukgp...@mid.individual.net>, Jolly Roger

<jolly...@pobox.com> wrote:

> >> Which means it would be far more if made available on Android since
> >> there are far more Android smartphones out there.  One source puts it
> >> at about 86% Android to 13% iOS (worldwide).  So Apple's "influence"
> >> would be much larger if they deployed Apple Pay to Android.
> >
> > Exactly. Do they want that market share
>
> Meh. Apple doesn't crave market share like a drug addict. There are
> other more important priorities. When will people get that through their
> heads?

another issue is the android device makers don't want apple pay.

google certainly isn't going to add it to android because they're
pushing google pay, plus it won't work on most android hardware anyway.

that leaves samsung, who has the dominant share of android devices, but
they already have their own samsung pay so they're not about to add
apple pay.

it's a stupid idea.

[Alan Browne]

Apple can take the position that "payments" are a fringe revenue
activity but I'm sure their overall strategy is very nuanced.

Making a payment at a merchant is no biggie, but if someone sees a
friend paying another friend for something with an iphone-iphone
transaction, then it could influence them to switch to iPhone next time
around.[1]

OTOH, if they deploy Apple Pay to Adroid, then it would reinforce the
Android user's faith in Android w/o any valuable return to Apple.

Steve Jobs' hatred of Android probably lingers well at Apple.

Contrary to that Apple Music is a service where the revenue value is in
delivering the music to any possible platform. It's worth roughly $10B
per year (depending on who's guesstimating). Also of course the
platform is already out there (iTunes) - though not on Android...

[1] Apple Pay Cash is not available in Canada yet, alas. Would come in
handy.

[Alan Browne]

On 2018-07-14 11:54, nospam wrote:
> In article <LZOdnWvhsvKhjNfG...@giganews.com>, Alan Browne
> <bitb...@blackhole.com> wrote:
>
>>>> Perhaps Apple Pay should be offered on other platforms as well.
>>>
>>> there's no point in that, given that apple pay has 90% of mobile
>>> transactions.
>>>
>>> <https://techcrunch.com/2017/10/23/apple-pay-now-in-20-markets-nabs-90-o
>>> f-all-contactless-transactions-where-active/>
>>> The advances point to how Apple wants to steal a march when it comes
>>> to using phones as a proxy for a card or cash, and there is some
>>> anecdotal evidence that it1s working: merchants and others who have
>>> partnered with Apple say that Apple Pay is accounting for 90 percent
>>> of all mobile contactless transactions globally in markets where it1s
>>> available.
>>
>> Which means it would be far more if made available on Android since
>> there are far more Android smartphones out there.
>
> nearly all android phones lack the necessary hardware to support apple
> pay (secure enclave), and that's assuming apple would even have an
> interest in doing so, which they do not. there is no point in it. none
> whatsoever.

It would really help if you read all that I wrote before the saliva
drips from your mouth on the way to the keyboard.

>> One source puts it at
>> about 86% Android to 13% iOS (worldwide). So Apple's "influence" would
>> be much larger if they deployed Apple Pay to Android.
>
> yet another market share fallacy.
>
> most of those android phones are low end devices which do not even have
> nfc, let alone a secure enclave.
>
> again, apple already has 90% mobile payment usage. the *most* they
> could gain is 10%, so it's not worth the effort.

Repeating things as if that makes them true is a Trumpian method ...

>
>> To be sure the article above points out deployment in higher value
>> markets, so that skews any attempt to guesstimate the value of including
>> Android.
>
> it doesn't skew anything. 90% of mobile payments are via apple pay.

The skew comes from a) that 90% number is not based on hard data (from
processors and banks) and b) that it only covers those markets where
Apple has prioritized. If you take in the worldwide view, which has a
very different distribution of iOS v. Android, then any attempt to
guesstimate the potential is skewed. Very.

The 90% claim is suspect - based on merchant samples rather than the
hard data.

>
>> Not that merchants want it that badly since (per my friend) he's getting
>> a hit of 5 cents per Apple Pay transaction on top of the CC/DB
>> transaction fees.
>
> bullshit.

I trust my friend's factual information. Not your hysterics.

>
> <https://www.cnet.com/news/apple-pay-to-generate-fees-from-banks-not-mer
> chants-report-says/>
> Apple has already confirmed that it won't charge merchants or
> consumers for card transactions, yet it's unclear how much in fees
> the company can generate from banks.
>
> <https://support.apple.com/en-us/ht204274>
> Are there additional fees to accept Apple Pay?
> No. Apple doesn't charge any additional fees.
>
> the *bank* pays a small fee to apple, which is taken out of the normal
> transaction fee they would have received with a normal transaction, and
> since fraud is effectively eliminated, they come out ahead.

Yet my friend is seeing line item charges for Apple Pay occurrences.

> and for what it's worth, a chinese restaurant near me pushes customers
> to pay *with* apple pay because he claims he pays a *lower* transaction
> fee when apple pay is used versus swipe/dip/tap and even google pay.
> i'm not entirely convinced, but he is very insistent that's the case.

It could be. It could be he doesn't understand what's happening. It
could be my friend's payment processor are "loading on". Who knows.
Fact is my friend pays 5 cents each time on top of the card fees. That
doesn't mean Apple see that money. But the merchant pays it.

>> He'd rather people simply tap-to-pay with their card
>> as they've been doing since long before Apple Pay came along.
>
> up until he gets hit with fraudulent charges. then he'll change his
> tune *real* fast.

I asked him how many fraud hits he's had. Ever.

Answer: 0

And even if it occurs, as long as his terminal has up to date s/w in it
(says it gets updated 2 or 3 times per year), then the responsibility
for a fraudulent transaction belongs to the processor or bank. His
liability is exactly 0 except where he takes down a verbal card number
(over the phone). He does that so rarely he can't remember the last
time it happened.

The other "fraud" he could be liable for is a magnetic stripe
transaction. Occurrence rate: Not 0, but might as well be for how
seldom it occurs. Younger clerks don't even know how to do it!

But that's because, unlike the US, tap to pay has been here for a long
time and widely so. Very secure. Of course you'll say Apple Pay is
more so - but for the difference it actually makes no difference v.
tap-to-pay.

[Jolly Roger]

On 2018-07-14, Alan Browne <bitb...@blackhole.com> wrote:
>
> Steve Jobs' hatred of Android probably lingers well at Apple.

Pffft... Many people were rightfully offended when Android blatantly
copied the design of iOS; and naturally many of them are still alive and
working at Apple. If you think Steve Jobs was the only one, you're
incredibly naive, incredibly ignorant, or both.

> [1] Apple Pay Cash is not available in Canada yet, alas. Would come
> in handy.

Too bad. You guys scoffed at and disparaged Apple Pay for years before
you finally got it, and then did an about face once it was launched,
which is on record in these very newsgroups. Eat cake.

[Jolly Roger]

On 2018-07-14, Alan Browne <bitb...@blackhole.com> wrote:

> On 2018-07-14 11:54, nospam wrote:
>>
>> again, apple already has 90% mobile payment usage. the *most* they
>> could gain is 10%, so it's not worth the effort.
>
> Repeating things as if that makes them true is a Trumpian method ...

Nope, it's the hard, cold truth:

TechCrunch:

"Apple Pay now in 20 markets, nabs 90% of all mobile contactless
transactions where active"

<https://techcrunch.com/2017/10/23/apple-pay-now-in-20-markets-nabs-90-of-all-contactless-transactions-where-active/>

Ignoring facts ("FAKE NEWS!!") and projecting your shortcomings onto
others is definitely Trumpian though. Kinda funny this coming from a
fucking *Canadian*... Ford supporter?

[nospam]

In article <ruGdnT2HTeovtdfG...@giganews.com>, Alan Browne

<bitb...@blackhole.com> wrote:

> >> To be sure the article above points out deployment in higher value
> >> markets, so that skews any attempt to guesstimate the value of including
> >> Android.
> >
> > it doesn't skew anything. 90% of mobile payments are via apple pay.
>
> The skew comes from a) that 90% number is not based on hard data (from
> processors and banks) and b) that it only covers those markets where
> Apple has prioritized. If you take in the worldwide view, which has a
> very different distribution of iOS v. Android, then any attempt to
> guesstimate the potential is skewed. Very.

it *is* based on hard data. there is no skew.

mobile payments are almost entirely apple pay.

the global market share of android devices is meaningless since most of
those devices *can't* do mobile payments and for those that can, it's a
clumsier process.

> The 90% claim is suspect - based on merchant samples rather than the
> hard data.

merchant samples confirm that apple pay is without question, used *far*
more than google pay.

your sample size of one is meaningless.

> >> Not that merchants want it that badly since (per my friend) he's getting
> >> a hit of 5 cents per Apple Pay transaction on top of the CC/DB
> >> transaction fees.
> >
> > bullshit.
>
> I trust my friend's factual information. Not your hysterics.

apple's factual information about how apple pay actually works is the
*only* information that should be trusted, and it clearly states that
merchants and customers do *not* pay any additional fees to use apple
pay. period.

> > <https://www.cnet.com/news/apple-pay-to-generate-fees-from-banks-not-mer
> > chants-report-says/>
> > Apple has already confirmed that it won't charge merchants or
> > consumers for card transactions, yet it's unclear how much in fees
> > the company can generate from banks.
> >
> > <https://support.apple.com/en-us/ht204274>
> > Are there additional fees to accept Apple Pay?
> > No. Apple doesn't charge any additional fees.
> >
> > the *bank* pays a small fee to apple, which is taken out of the normal
> > transaction fee they would have received with a normal transaction, and
> > since fraud is effectively eliminated, they come out ahead.
>
> Yet my friend is seeing line item charges for Apple Pay occurrences.

if so, then it's his payment processor adding fees, *not* apple.

he's also being ripped off, as there is no valid reason to charge extra
fees for what has significantly lower risk (as in, effectively zero).

don't blame apple for what a third party is doing. it's nothing more
than a money grab.

[Alan Browne]

On 2018-07-14 13:55, Jolly Roger wrote:
> On 2018-07-14, Alan Browne <bitb...@blackhole.com> wrote:
>>
>> Steve Jobs' hatred of Android probably lingers well at Apple.
>
> Pffft... Many people were rightfully offended when Android blatantly
> copied the design of iOS; and naturally many of them are still alive and
> working at Apple. If you think Steve Jobs was the only one, you're
> incredibly naive, incredibly ignorant, or both.

Re-read what I wrote instead of slinging insults.

>
>> [1] Apple Pay Cash is not available in Canada yet, alas. Would come
>> in handy.
>
> Too bad. You guys scoffed at and disparaged Apple Pay for years before
> you finally got it, and then did an about face once it was launched,
> which is on record in these very newsgroups. Eat cake.

Not at all. What I scoffed at was the notion that it was anything
special and yes, that is on record in these NG's.

Summary: We've had "tap to pay" cards for many years before Apple Pay.
Indeed a predecessor to credit/debit cards with tap to pay was gas RFID
cards (Shell, Petro-Canada etc) that went back to the early 2000's.
(These were little keychain devices - that account linked to whatever CC
you wanted it linked to. Very convenient, very fast - more than a
decade before Apple Pay).

What made Apple Pay look so great to Americans was the lingering hang on
of magnetic stripe cards in the US that was all but dead in the ROTW
long before Apple Pay. (We've had chipped cards for a long time before
Tap To Pay).

Apple Pay is nice, but it hasn't solved any huge issues in my life. I'd
like the ability to xfer cash to my son (or v-v!@).

But for now I do it for free with Interac straight to his bank account
in any case. (He receives an e-mail and then goes to his bank to
complete the payment; it can be set up to automatically receive (no
action needed) and it can be used to ask for payment too... and yes, I
can do that from my iPhone/android phone or any web page ...).

[Alan Browne]

On 2018-07-14 14:02, Jolly Roger wrote:
> On 2018-07-14, Alan Browne <bitb...@blackhole.com> wrote:
>> On 2018-07-14 11:54, nospam wrote:
>>>
>>> again, apple already has 90% mobile payment usage. the *most* they
>>> could gain is 10%, so it's not worth the effort.
>>
>> Repeating things as if that makes them true is a Trumpian method ...
>
> Nope, it's the hard, cold truth:
>
> TechCrunch:
>
> "Apple Pay now in 20 markets, nabs 90% of all mobile contactless
> transactions where active"

QUOTE FROM SAME ARTICLE:

merchants and others who have partnered with Apple say that Apple Pay is

accounting for 90 percent of all mobile contactless transactions
globally in markets where it’s available.

END QUOTE

See the word "say" in there?
See the words "in markets where it's available"?

So, first there's what people say. (Not hard data).
Then "where" available.

Then it's in _20_ markets. (Not zie weldt).

Which is why repeating soft data as hard is quite Trumpian...

[Alan Browne]

On 2018-07-14 14:17, nospam wrote:
> In article <ruGdnT2HTeovtdfG...@giganews.com>, Alan Browne
> <bitb...@blackhole.com> wrote:
>
>>>> To be sure the article above points out deployment in higher value
>>>> markets, so that skews any attempt to guesstimate the value of including
>>>> Android.
>>>
>>> it doesn't skew anything. 90% of mobile payments are via apple pay.
>>
>> The skew comes from a) that 90% number is not based on hard data (from
>> processors and banks) and b) that it only covers those markets where
>> Apple has prioritized. If you take in the worldwide view, which has a
>> very different distribution of iOS v. Android, then any attempt to
>> guesstimate the potential is skewed. Very.
>
> it *is* based on hard data. there is no skew.

Of course it's skewed. There is no way to come to a hard number from
what was "said" in an article, from 20 markets and then look at the ROTW
and determine a possible overall market share. Any such estimate would
be skewed by the very nature of the inputs.

>
> mobile payments are almost entirely apple pay.
>
> the global market share of android devices is meaningless since most of
> those devices *can't* do mobile payments and for those that can, it's a
> clumsier process.

I saw a fella making payment in the store with an Android phone the
other day. 0 difference with Apple Pay. After all, it's just a
tap-to-pay transaction.

>
>> The 90% claim is suspect - based on merchant samples rather than the
>> hard data.
>
> merchant samples confirm that apple pay is without question, used *far*
> more than google pay.
>
> your sample size of one is meaningless.

Nice flip there, but I didn't make any claims. OTOH, that " ... say 90%
..." is not backed by hard data. If so, present it.

>
>>>> Not that merchants want it that badly since (per my friend) he's getting
>>>> a hit of 5 cents per Apple Pay transaction on top of the CC/DB
>>>> transaction fees.
>>>
>>> bullshit.
>>
>> I trust my friend's factual information. Not your hysterics.
>
> apple's factual information about how apple pay actually works is the
> *only* information that should be trusted, and it clearly states that
> merchants and customers do *not* pay any additional fees to use apple
> pay. period.

I never said it was Apple making the charge. My friend sees the charge
from his payment processor.

>
>>> <https://www.cnet.com/news/apple-pay-to-generate-fees-from-banks-not-mer
>>> chants-report-says/>
>>> Apple has already confirmed that it won't charge merchants or
>>> consumers for card transactions, yet it's unclear how much in fees
>>> the company can generate from banks.
>>>
>>> <https://support.apple.com/en-us/ht204274>
>>> Are there additional fees to accept Apple Pay?
>>> No. Apple doesn't charge any additional fees.
>>>
>>> the *bank* pays a small fee to apple, which is taken out of the normal
>>> transaction fee they would have received with a normal transaction, and
>>> since fraud is effectively eliminated, they come out ahead.
>>
>> Yet my friend is seeing line item charges for Apple Pay occurrences.
>
> if so, then it's his payment processor adding fees, *not* apple.

I never said it was Apple adding the fee.

To the merchant it does not matter how or why fees are added, they are
rents on his income. Again, no big deal for my friend do to a) low
frequency of occurence and b) high value per transaction but to someone
else it could be significant.

>
> he's also being ripped off, as there is no valid reason to charge extra
> fees for what has significantly lower risk (as in, effectively zero).

Lower risk than what? Unlike the Balkans otherwise known as the USA the
ROTW went away from high risk magnetic stripe cards to chipped and tap
to pay cards years ago greatly reducing the risk.

The risk for chipped cards is very low. The risk for tap-to-pay is
negligible.

Why, my friend says, he is absolutely NOT liable for fraud on chip or
tap-to-pay cards.

As to the processor, I would understand that they have a reason to
charge as they have another interface or additional processing to go
through. 5 cents is excessive (IMO), but there is always a cost to
everything.

>
> don't blame apple for what a third party is doing. it's nothing more
> than a money grab.

Again, I didn't blame Apple - but you do try to twist things around -
par for you.

[Arlen Holder]

In response to the following from nospam:

> that also ignores the fact that most android phones can't support apple
> pay even if apple wanted to bother doing it.

Let's test your facts, nospam, since I personally have no experience with
any mobile device payment system.

As you are well aware, it's a fact that I bought a handful of el cheapo
Android phones as last-minute Christmas stocking stuffers.

Can those el-cheapo $130 Android phones "support Apple Pay"?

[Arlen Holder]

In response to the following from sms:

> As much as you hate iTunes, being able to have a single front end for
> streaming and stored music is a good feature.

I am eminantly reasonable, sms, so rest assured I recognize the value of a
"single front end".

But if that single front end comes with a sharpened pole that gets
visciously shoved up your back end at the same time, then the cons outweigh
the pros of that "single front end".

Hence, I may need to be clear that the reason I dislike the iTunes
abomination are the same reasons lots of people dislike the iTunes
abomination - much of which is due the Orwellian restrictions more so than
the huge bloat, such that there is well known extreme danger for a use
model such as mine, which is to connect any Apple mobile device to any
personal computer of any operating system and, having the complete freedom
to do what I want with the files on all those systems.

I don't change my stripes, so you know that complete freedom is what I care
about - not Draconian restrictions - which is where iTunes is an
abomination.

The fact it's a single front end is fine.
It's the sharpened pole Apple shoves up your butt that I don't appreciate.

>> 2. Apple Pay electronic payment
>
> Offering Apple Pay on Android would cause a big increase in mobile
> payments, of which Apple gets a small cut.

I'm going to agree with you.

You know Android phones are so cheap nowadays that I bought a handful of
el-cheapo $130 phones recently, where all I want to ask you (since I know
nospam will wiggle out of the question playing his silly childish games) is
whether those dirt-cheap phones can "handle Apple Pay".

Can those dirt-cheap last-minute stocking stuffers handle Apple Pay?

> The family plans for Apple Music and Spotify are pretty good deals,
> though I don't have unlimited data so I probably wouldn't sign up at
> this point.

I'm not against a good deal but how is paying a monthly subscription a
better deal than just streaming or downloading all the music you want, for
free?

Is it yet another tax on stupidity?

Since I know nospam will yell and scream that using NewPipe is "illegal",
if it were, then Google would have stopped them long ago, since the source
code is freely available and since Google allowed NewPipe clones on their
site (and other issues I don't want to get into such as the fact that the
software uses perfectly legal public calls, etc.).

My only question is whether you consider Apple Music a tax on stupidity?
Specifically, it takes a bit of brains to legally get all the music you
want for free, but it can easily be done for anyone with brains.

This is a serious question of you, sms.

While music isn't my shtick, if music is what someone wants, how does Apple
Music at a monthly fee do anything better than, say, something like New
Pipe does for me for free?

[Arlen Holder]

In response to the following from Alan Browne:

> since most of
>> those devices *can't* do mobile payments and for those that can, it's a
>> clumsier process.
>
> I saw a fella making payment in the store with an Android phone the
> other day. 0 difference with Apple Pay. After all, it's just a
> tap-to-pay transaction.

Hi Alan Browne,

I have no experience with mobile device payment systems, and yet I have a
serious question, which I've asked nospam, but I expect him to give a
childish answer, so I'll ask you this serious question.

It seems nospam asserts that "most" Android phones can't suupport an Apple
Pay like system, where, as you are aware, I buy cheap Android phones all
the time - where Android prices are dropping (e.g., the 8GB Nexus 5 and 8GB
MotoG I bought years ago as gifts were almnost twice as expensive as the
32GB LG Stylo 3 Plus phones I bough a handful of recently).

Given that nospam's guessare are almost always wrong, and given that I can
find better less expensive Android phones now, more than ever before, let's
test out nospam's "guess" using the real purchase of my $130 el cheap gift
phones as a test case.

Q: Can my el cheapo dirt-cheap $130 Android phones support Apple Pay?

[Alan Browne]

1) No because it does not have the requisite Apple Pay hardware required
by Apple Pay's spec. eg: the Secure Enclave as implemented by Apple.
More important is how Apple Pay is implemented as an interface to the
banks - and that will be different than, Google Pay.

2) All that matters to you is if your specific Android phone supports
tap-to-pay. Whether that includes your $130 phone, I don't know. Look
at its spec - if it supports Google Pay and your bank and cards support
it then that's all that counts.

Nospam is probably on about "the majority of Android devices" and he may
well be right. I'm certainly not wasting my time on your trolling
antics for that.

[Jolly Roger]

On 2018-07-14, Alan Browne <bitb...@blackhole.com> wrote:
> On 2018-07-14 13:55, Jolly Roger wrote:
>> On 2018-07-14, Alan Browne <bitb...@blackhole.com> wrote:
>>>
>>> Steve Jobs' hatred of Android probably lingers well at Apple.
>>
>> Pffft... Many people were rightfully offended when Android blatantly
>> copied the design of iOS; and naturally many of them are still alive
>> and working at Apple. If you think Steve Jobs was the only one,
>> you're incredibly naive, incredibly ignorant, or both.
>
> Re-read what I wrote

Don't need to since it's quoted above for all to see.

>>> [1] Apple Pay Cash is not available in Canada yet, alas. Would come
>>> in handy.
>>
>> Too bad. You guys scoffed at and disparaged Apple Pay for years
>> before you finally got it, and then did an about face once it was
>> launched, which is on record in these very newsgroups. Eat cake.
>
> Not at all.

Yes, at all.

> What I scoffed at was the notion that it was anything special and yes,
> that is on record in these NG's.

You scoffed. End of story. Eat cake.

> What made Apple Pay look so great to Americans was the lingering hang
> on of magnetic stripe cards in the US that was all but dead in the
> ROTW long before Apple Pay.

Nope. It's still faster, more convenient, and more secure than chipped
cards, which the majority of Americans use today. You don't get to tell
Americans what we fucking like about Apple Pay. You can deny it all you
want, but it doesn't change the objective *fact* that it's both *faster*
and more *convenient* to hold your Apple Watch to a reader than pulling
out your wallet and fumbling through a stack of credit cards, or that it
is more secure than carrying a physical credit card with you wherever
you go that can get lost or stolen and used while your Apple device
cannot. Your refusal to see the obvious objective benefits don't make
them magically disappear, and it also means we laugh at you when you hem
and haw about Apple Pay Cash not being available in your podunk country.
Boo fucking hoo.

> Apple Pay is nice, but it hasn't solved any huge issues in my life.

Denial fits you. And your opinion doesn't change reality for others, nor
does it matter to them. You won't change a single thing for the millions
of people who use Apple Pay and enjoy it. You're powerless.

[Alan Browne]

Trivial. I've never been close to 5 GB because I only keep sparse
information in iCloud. Notes, reminders, etc.

If I had a valid reason to keep reams of data in iCloud, then I wouldn't
care if I had to pay for it.

>
>> Apple's goal shouldn't even be to provide the best apps IMO.
>
> This is a critical observation on your part, which I admire.
>
> I agree with you that Apple will likely fail if they attempt to make a
> series of best-in-class applications in terms of flexibility and power,
> since, as we all know, Apple restricts what apps can do (for a variety of
> assumed but never really known reasons).
>
> Why does Apple restrict what apps can do?

- Security
- Simplicity
- Maintainability

The last two go very much hand in hand as maintainability costs are
proportional to the square of complexity. (ish - probably Cm ∝ K^2 / 2)
where Cm is maintenance cost and K is the complexity as defined by
combinations).

>
> That's a mystery to me - simply because there are so many things that iOS
> apps can't do that there can't be a single reason for the functionality
> restrictions.

Several reasons. Above.

>> Their goal
>> should be to provide an OS and development environment that allows
>> developers to do so while taking advantage of the integration
>> environment.
>
> This is a very astute point that you make, with respect to the original
> question, which is that Apple doesn't have to create the best-in-class
> apps, when the *developers* are the ones who are supposed to do that for
> them.

That doesn't exclude Apple from making BiC's; but where someone else is
better at it they certainly don't impede them.

>
>> That is more valuable by far than Apple coming up with any
>> "best-in-class" attempt they might make. That would be a waste of
>> resources as well as counter productive when there are so many app
>> makers out there who specialize in a particular area.
>
> I can't disagree, but then we have to wonder what Apple's strategy is when
> they *attempt* to make a best-in-class mapping app.

Attempts include failures. Apple's arrogance in this area has cost them
dearly.

>
> Maybe if someone else other than Google had made the best mapping app, then
> maybe Apple wouldn't be sinking a lot of money into Apple Maps?
>
> Dunno. But it's a good point that Apple doesn't have to make the
> best-in-class app if developers create a best-in-class app for them.

I don't know if Google Maps is the best in class. It's 'my' best, but I
wouldn't be surprised to find better. But then I don't use it much on
my phone except at the penultimate part of finding somewhere.

>
>> Anyway, do continue with your feeble trolling.
>
> It's a serious question, where I always respond in like manner and tone to
> the perceived intent and quality of the post I'm responding to.

No, you just put up straw and hope someone punches. You've come up with
a nice obsequious format of late, but you're still a troll. Dyed in the
wool.

[nospam]

In article <pidh19$r3l$1...@news.mixmin.net>, Arlen Holder

<arlen...@nospam.net> wrote:

>
> Since I know nospam will yell and scream that using NewPipe is "illegal",

i never said it's illegal.

i said it violates youtube's terms of service, and it does.

> if it were, then Google would have stopped them long ago,

they did.

newpipe is not available in the play store.

> since the source
> code is freely available and since Google allowed NewPipe clones on their
> site (and other issues I don't want to get into such as the fact that the
> software uses perfectly legal public calls, etc.).

using public api calls isn't the problem.

the problem is that it violates youtube's terms of service, and google
owns youtube.

google has no interest in hosting a product that is designed to violate
their terms of service.

> My only question is whether you consider Apple Music a tax on stupidity?
> Specifically, it takes a bit of brains to legally get all the music you
> want for free, but it can easily be done for anyone with brains.

it's not possible to legally get all the music you want for free, or
even a tiny portion of it.

> While music isn't my shtick,

then why do you keep yapping about how you go to the library to steal
music?

> if music is what someone wants, how does Apple
> Music at a monthly fee do anything better than, say, something like New
> Pipe does for me for free?

because streaming services, such as apple music, spotify, etc., are
legal.

what you're doing is piracy.

[nospam]

In article <pidg9i$pso$1...@news.mixmin.net>, Arlen Holder

no. apple pay is not supported on android, period.

google pay works on *some* android phones but not all of them.

post the model # of this mystery android phone so its specs can be
checked.

chances are very high that it doesn't have nfc, which would prevent it
from supporting google pay, never mind apple pay.

[nospam]

In article <paidnVpxUKiG3tfG...@giganews.com>, Alan Browne

<bitb...@blackhole.com> wrote:

> >>>> To be sure the article above points out deployment in higher value
> >>>> markets, so that skews any attempt to guesstimate the value of including
> >>>> Android.
> >>>
> >>> it doesn't skew anything. 90% of mobile payments are via apple pay.
> >>
> >> The skew comes from a) that 90% number is not based on hard data (from
> >> processors and banks) and b) that it only covers those markets where
> >> Apple has prioritized. If you take in the worldwide view, which has a
> >> very different distribution of iOS v. Android, then any attempt to
> >> guesstimate the potential is skewed. Very.
> >
> > it *is* based on hard data. there is no skew.
>
> Of course it's skewed. There is no way to come to a hard number from
> what was "said" in an article, from 20 markets and then look at the ROTW
> and determine a possible overall market share. Any such estimate would
> be skewed by the very nature of the inputs.

it's not skewed.

mobile payments are a subset of all payments, and of those, apple pay
is used in 90% of them.

even if you don't believe that number, the reality is that apple pay is
by far the dominant mobile payment system used.

> > mobile payments are almost entirely apple pay.
> >
> > the global market share of android devices is meaningless since most of
> > those devices *can't* do mobile payments and for those that can, it's a
> > clumsier process.
>
> I saw a fella making payment in the store with an Android phone the
> other day. 0 difference with Apple Pay.

not all android devices work that way.

for many of them, it requires unlocking the phone first, whereas with
apple pay, it works directly from the lock screen.

it's even easier with an apple watch. no phone needed.

> After all, it's just a
> tap-to-pay transaction.

yep, which is why your friend is being ripped off.

> >> The 90% claim is suspect - based on merchant samples rather than the
> >> hard data.
> >
> > merchant samples confirm that apple pay is without question, used *far*
> > more than google pay.
> >
> > your sample size of one is meaningless.
>
> Nice flip there, but I didn't make any claims. OTOH, that " ... say 90%
> ..." is not backed by hard data. If so, present it.

you did, and it is.

feel free to provide 'hard data' that shows otherwise.

> >>>> Not that merchants want it that badly since (per my friend) he's getting
> >>>> a hit of 5 cents per Apple Pay transaction on top of the CC/DB
> >>>> transaction fees.
> >>>
> >>> bullshit.
> >>
> >> I trust my friend's factual information. Not your hysterics.
> >
> > apple's factual information about how apple pay actually works is the
> > *only* information that should be trusted, and it clearly states that
> > merchants and customers do *not* pay any additional fees to use apple
> > pay. period.
>
> I never said it was Apple making the charge. My friend sees the charge
> from his payment processor.

you said merchants (plural) don't want apple pay because of extra fees.

merchants (or customers) do not pay extra fees for apple pay. period.

a payment processor might charge additional fees, but that's unique to
that particular payment processor and is also a rip off.

> >>> <https://www.cnet.com/news/apple-pay-to-generate-fees-from-banks-not-mer
> >>> chants-report-says/>
> >>> Apple has already confirmed that it won't charge merchants or
> >>> consumers for card transactions, yet it's unclear how much in fees
> >>> the company can generate from banks.
> >>>
> >>> <https://support.apple.com/en-us/ht204274>
> >>> Are there additional fees to accept Apple Pay?
> >>> No. Apple doesn't charge any additional fees.
> >>>
> >>> the *bank* pays a small fee to apple, which is taken out of the normal
> >>> transaction fee they would have received with a normal transaction, and
> >>> since fraud is effectively eliminated, they come out ahead.
> >>
> >> Yet my friend is seeing line item charges for Apple Pay occurrences.
> >
> > if so, then it's his payment processor adding fees, *not* apple.
>
> I never said it was Apple adding the fee.
>
> To the merchant it does not matter how or why fees are added, they are
> rents on his income. Again, no big deal for my friend do to a) low
> frequency of occurence and b) high value per transaction but to someone
> else it could be significant.

again, you said merchants do not want apple pay due to fees.

since there are no fees for accepting apple pay, your statement is
wrong.

what one particular payment processor does is their doing, not apple.

> > he's also being ripped off, as there is no valid reason to charge extra
> > fees for what has significantly lower risk (as in, effectively zero).
>
> Lower risk than what? Unlike the Balkans otherwise known as the USA the
> ROTW went away from high risk magnetic stripe cards to chipped and tap
> to pay cards years ago greatly reducing the risk.

chip cards have made it much harder to copy a card (although not
impossible), which just means the bad guys will move to online
purchases, where no chip is needed.

for an online purchase, the user types in the card information, just
like they always have. the chip is not a factor. there is no extra
protection with a chip.

apple pay, both in-store and online, for all intents, can't be
compromised and unlike a stolen card, a stolen iphone can't be used for
apple pay purchases because the fingerprint or face will not match.

also, if a merchant's database is hacked, the bad guys only have a
device number. they don't know the algorithm to calculate the one-time
token, nor do they have the keys to do so even if they did, nor do they
know the device it's supposed to be from.

in other words, the chances that someone can spoof apple pay is
basically zero.

> The risk for chipped cards is very low. The risk for tap-to-pay is
> negligible.

nope.

a stolen card can be tapped to buy stuff without issue, up until it's
reported stolen or the bank decides something isn't quite right. that
could be fairly quickly or maybe not for a few days.

a stolen ios device *can't* be used to make a purchase at all. period.

> Why, my friend says, he is absolutely NOT liable for fraud on chip or
> tap-to-pay cards.

that isn't an absolute and it's still a hassle even if the bank
ultimately covers it.

> As to the processor, I would understand that they have a reason to
> charge as they have another interface or additional processing to go
> through. 5 cents is excessive (IMO), but there is always a cost to
> everything.

there is no additional interface and there is no extra cost.

as you said above, it's just another tap to pay transaction.

> > don't blame apple for what a third party is doing. it's nothing more
> > than a money grab.
>
> Again, I didn't blame Apple -

actually, you did.

> but you do try to twist things around -
> par for you.

nope.

[nospam]

In article <ktSdnc2xZ7sO3dfG...@giganews.com>, Alan Browne

<bitb...@blackhole.com> wrote:

> >
> > "Apple Pay now in 20 markets, nabs 90% of all mobile contactless
> > transactions where active"
>
> QUOTE FROM SAME ARTICLE:
> merchants and others who have partnered with Apple say that Apple Pay is
> accounting for 90 percent of all mobile contactless transactions

> globally in markets where it零 available.

> END QUOTE
>
> See the word "say" in there?
> See the words "in markets where it's available"?

google pay is available in those very same areas, as is contactless
tap/pay.

with very rare exception, apple pay (and google pay) works anywhere
contactless is accepted, whether or not local banks support it (i.e.,
will allow a card to be added).

[nospam]

In article <ktSdndKxZ7trotfG...@giganews.com>, Alan Browne

<bitb...@blackhole.com> wrote:

>
> What made Apple Pay look so great to Americans was the lingering hang on
> of magnetic stripe cards in the US that was all but dead in the ROTW
> long before Apple Pay. (We've had chipped cards for a long time before
> Tap To Pay).

no, what makes apple pay great (and not just for looks) is that it's
effectively impossible to hack and that it does not provide any user
identifiable information to the merchant, not even a name, which makes
data mining linked back to the user impossible.

only if the person provides a name to the merchant (versus read off the
card) will they know who bought the product or service, such as when an
online purchase must be delivered.

otherwise, it's just a number without a name, one which can be changed
at any time, breaking any links the merchant might have on that number.

merchants make a lot of money selling user data so they aren't aren't
thrilled with that aspect, but consumers definitely are.

[nospam]

In article <KKWdnTODx6OawdfG...@giganews.com>, Alan Browne

<bitb...@blackhole.com> wrote:

> > I can't disagree, but then we have to wonder what Apple's strategy is when
> > they *attempt* to make a best-in-class mapping app.
>
> Attempts include failures. Apple's arrogance in this area has cost them
> dearly.

apple maps isn't the way it is due to arrogance.

when the iphone came out, google maps was the only option.

apple wanted to offer turn by turn directions, except that google
refused to allow others to offer it so that android would have a
competitive advantage.

apple had *no* choice but to find an alternative, and fast.

apple obtained assorted map data from various sources from various
companies in various formats and tried to link it all together, except
that didn't work out quite so well.

they are now rebuilding the entire product with their own data so that
it does exactly what they want. it's a huge undertaking but they have
the resources to do it.

[Alan Browne]

On 2018-07-14 16:20, Jolly Roger wrote:
> On 2018-07-14, Alan Browne <bitb...@blackhole.com> wrote:
>> On 2018-07-14 13:55, Jolly Roger wrote:
>>> On 2018-07-14, Alan Browne <bitb...@blackhole.com> wrote:
>>>>
>>>> Steve Jobs' hatred of Android probably lingers well at Apple.
>>>
>>> Pffft... Many people were rightfully offended when Android blatantly
>>> copied the design of iOS; and naturally many of them are still alive
>>> and working at Apple. If you think Steve Jobs was the only one,
>>> you're incredibly naive, incredibly ignorant, or both.
>>
>> Re-read what I wrote
>
> Don't need to since it's quoted above for all to see.

Exactly. And since he's dead, whatever "lingering hatred" of his that
lives on (your words too), so Steve Jobs could not be who I was
referring to ... so no I didn't think he was the only one and you can
retract the rest of your nonsense at your leisure.

>
>>>> [1] Apple Pay Cash is not available in Canada yet, alas. Would come
>>>> in handy.
>>>
>>> Too bad. You guys scoffed at and disparaged Apple Pay for years
>>> before you finally got it, and then did an about face once it was
>>> launched, which is on record in these very newsgroups. Eat cake.
>>
>> Not at all.
>
> Yes, at all.

High School not out for the summer yet?

>
>> What I scoffed at was the notion that it was anything special and yes,
>> that is on record in these NG's.
>
> You scoffed. End of story. Eat cake.
>
>> What made Apple Pay look so great to Americans was the lingering hang
>> on of magnetic stripe cards in the US that was all but dead in the
>> ROTW long before Apple Pay.
>
> Nope. It's still faster, more convenient, and more secure than chipped
> cards, which the majority of Americans use today. You don't get to tell
> Americans what we fucking like about Apple Pay. You can deny it all you

Whiner. Fact is we had chipped cards AND tap to pay LONG before the US.

So any advantage of Apple Pay presented as thin, watery stuff.

> want, but it doesn't change the objective *fact* that it's both *faster*
> and more *convenient* to hold your Apple Watch to a reader than pulling
> out your wallet and fumbling through a stack of credit cards, or that it
> is more secure than carrying a physical credit card with you wherever
> you go that can get lost or stolen and used while your Apple device
> cannot. Your refusal to see the obvious objective benefits don't make

Went to get gas for the lawn mower today. That station's card reader at
the pump was chip only (not even tap-to-pay). So, bust there.

As stated in the past, I have to carry various things in any case, so
cards are no issue. (Even if I use Apple Pay for many things).

> them magically disappear, and it also means we laugh at you when you hem
> and haw about Apple Pay Cash not being available in your podunk country.
> Boo fucking hoo.

That's Apple's problem. In the mean time (actually for quite a long
time) I've been transferring money to people and v-v in any case using
Interac.

Boo what you were saying?

>
>> Apple Pay is nice, but it hasn't solved any huge issues in my life.
>
> Denial fits you. And your opinion doesn't change reality for others, nor
> does it matter to them. You won't change a single thing for the millions
> of people who use Apple Pay and enjoy it. You're powerless.

Your slobbering devotion to an ant hill makes you even more powerless.

[Alan Browne]

On 2018-07-14 16:37, nospam wrote:
> In article <ktSdndKxZ7trotfG...@giganews.com>, Alan Browne
> <bitb...@blackhole.com> wrote:
>
>>
>> What made Apple Pay look so great to Americans was the lingering hang on
>> of magnetic stripe cards in the US that was all but dead in the ROTW
>> long before Apple Pay. (We've had chipped cards for a long time before
>> Tap To Pay).
>
> no, what makes apple pay great (and not just for looks) is that it's
> effectively impossible to hack and that it does not provide any user
> identifiable information to the merchant, not even a name, which makes
> data mining linked back to the user impossible.

Neither does tap-to-pay other than the CC number. The 3 digit security
code is not transmitted. Nor the user's name. Nothing the merchant can
use. And the merchant, transaction to transaction from the same card
sees different numbers every time...

Finally of course, there is no liability to the card holder nor to the
merchant for fraudulent charges on compliant systems.

[Alan Browne]

On 2018-07-14 16:37, nospam wrote:

> In article <KKWdnTODx6OawdfG...@giganews.com>, Alan Browne
> <bitb...@blackhole.com> wrote:
>
>>> I can't disagree, but then we have to wonder what Apple's strategy is when
>>> they *attempt* to make a best-in-class mapping app.
>>
>> Attempts include failures. Apple's arrogance in this area has cost them
>> dearly.
>
> apple maps isn't the way it is due to arrogance.

Apple's declaration of ultimate map experience was pure hubris.

>
> when the iphone came out, google maps was the only option.
>
> apple wanted to offer turn by turn directions, except that google
> refused to allow others to offer it so that android would have a
> competitive advantage.
>
> apple had *no* choice but to find an alternative, and fast.

Fair enough. But the promise was way over the delivery. That history
is clear enough.

>
> apple obtained assorted map data from various sources from various
> companies in various formats and tried to link it all together, except
> that didn't work out quite so well.
>
> they are now rebuilding the entire product with their own data so that
> it does exactly what they want. it's a huge undertaking but they have
> the resources to do it.

Can't wait.

[Lewis]

In message <140720181637152518%nos...@nospam.invalid> nospam <nos...@nospam.invalid> wrote:
> In article <KKWdnTODx6OawdfG...@giganews.com>, Alan Browne
> <bitb...@blackhole.com> wrote:

>> > I can't disagree, but then we have to wonder what Apple's strategy is when
>> > they *attempt* to make a best-in-class mapping app.
>>
>> Attempts include failures. Apple's arrogance in this area has cost them
>> dearly.

> apple maps isn't the way it is due to arrogance.

> when the iphone came out, google maps was the only option.

> apple wanted to offer turn by turn directions, except that google
> refused to allow others to offer it so that android would have a
> competitive advantage.

Google was refusing to renew the contract with Apple unless
they shared the customer data with Google. In exchange, Google offered
TBT directions. Apple told Google to fuck off.

> apple had *no* choice but to find an alternative, and fast.

Or give up their customer's data, which they were unwilling to do.

> they are now rebuilding the entire product with their own data so that
> it does exactly what they want. it's a huge undertaking but they have
> the resources to do it.

They have been rebuilding it for years, since Apple Maps launched, in
fact. This is not a new thing they just started, it's taken them years
to get here.

--
"Oh my god. What can it be? We're all doomed! Who's flying this thing!?"
(pause) "Oh right, that would be me, back to work."

[Jolly Roger]

On 2018-07-14, Alan Browne <bitb...@blackhole.com> wrote:

> On 2018-07-13 17:02, Arlen Holder wrote:
>>
>> While the "hidden glue" is the iCloud, one issue is that you have to rent
>> your data back from Apple, if you're not careful to keep below the rather
>> puny 5GB limits.
>
> Trivial. I've never been close to 5 GB because I only keep sparse
> information in iCloud. Notes, reminders, etc.

As has been previously mentioned during the resident nym-shifting troll
currently known as "Arlen Holder"'s last iCloud bitch fest, those things
don't count against your 5GB. iCloud backups only include information
and settings stored on your device. They don't include the information
already stored in iCloud, like apps and music from the App/iTunes store,
Contacts, Calendars, Reminders, Bookmarks, Mail, Notes, shared photos,
iCloud Photo Library, My Photo Stream, Health data, and files you store
in iCloud Drive. And that's why most people get by just fine with the
free 5GB package - it's a sufficient amount of space for their backups
since a lot of their data is already in iCloud and does not count
against their 5GB allotment.

[Alan Browne]

On 2018-07-14 17:09, Jolly Roger wrote:
> On 2018-07-14, Alan Browne <bitb...@blackhole.com> wrote:
>> On 2018-07-13 17:02, Arlen Holder wrote:
>>>
>>> While the "hidden glue" is the iCloud, one issue is that you have to rent
>>> your data back from Apple, if you're not careful to keep below the rather
>>> puny 5GB limits.
>>
>> Trivial. I've never been close to 5 GB because I only keep sparse
>> information in iCloud. Notes, reminders, etc.
>
> As has been previously mentioned during the resident nym-shifting troll
> currently known as "Arlen Holder"'s last iCloud bitch fest, those things
> don't count against your 5GB. iCloud backups only include information
> and settings stored on your device. They don't include the information
> already stored in iCloud, like apps and music from the App/iTunes store,
> Contacts, Calendars, Reminders, Bookmarks, Mail, Notes, shared photos,
> iCloud Photo Library, My Photo Stream, Health data, and files you store
> in iCloud Drive. And that's why most people get by just fine with the
> free 5GB package - it's a sufficient amount of space for their backups
> since a lot of their data is already in iCloud and does not count
> against their 5GB allotment.

Wonderful. Even so I keep very little there.

The Apple rates for other plans seem reasonable enough if one needed
them. Dropbox is more expensive - but does have "history" for 120 days.
More useful for business I guess.

The Apple 200G/2TB plans can be "family shared" which is interesting too.

[sms]

On 7/14/2018 9:45 AM, Alan Browne wrote:

<snip>

> But that's because, unlike the US, tap to pay has been here for a long
> time and widely so.  Very secure.  Of course you'll say Apple Pay is
> more so - but for the difference it actually makes no difference v.
> tap-to-pay.

One article stated that the percentage fee was slightly less for Apple
Pay transactions versus swiped credit card transactions (up to 10%
less), i.e. instead of 1.6% + 10¢ per transaction it would be 1.44% +
10¢ per transaction. Not sure if this is still the case.

Assuming a 10% discount on fees, a business that did say $100K of credit
card tranactions (5000 $20 transactions) a month would pay $1940 in
monthly fees rather than $2100, a savings of $160 per month. Each $20
transaction would cost 3.2¢ less, each $30 transaction would cost 4.8¢
less. Not a huge savings, but better than nothing. Since presumably
almost no business would be patronized based on whether or not they took
Apple Pay, there has to be an upside to the business to accept it. A
small savings in transaction costs, plus faster transactions, are two
upsides.

Maybe that 0.15% in revenue from each transaction is just too small to
bother about, and putting Apple Pay on Android would create the wrong
perception. Of course once a merchant is set up for Apple Pay, it's not
really any more trouble to accept Google Pay as well. Around my area
it's rare to see a store that accepts Apple Pay but not Google Pay, or
vice-versa, though the obvious ones exist. Most Android phones about
$150 have the necessary hardware to do mobile payments, so there's a lot
of upside potential for mobile payments.

Speaking only for myself.

[nospam]

In article <P5mdnc3jGvAb_dfG...@giganews.com>, Alan Browne

<bitb...@blackhole.com> wrote:

> >> What made Apple Pay look so great to Americans was the lingering hang
> >> on of magnetic stripe cards in the US that was all but dead in the
> >> ROTW long before Apple Pay.
> >
> > Nope. It's still faster, more convenient, and more secure than chipped
> > cards, which the majority of Americans use today. You don't get to tell
> > Americans what we fucking like about Apple Pay. You can deny it all you
>
> Whiner. Fact is we had chipped cards AND tap to pay LONG before the US.
>
> So any advantage of Apple Pay presented as thin, watery stuff.

nope.

apple pay is faster and significantly more secure than chip cards.

[nospam]

In article <pidscs$aka$1...@dont-email.me>, sms

<scharf...@geemail.com> wrote:

>
> One article stated that the percentage fee was slightly less for Apple
> Pay transactions versus swiped credit card transactions (up to 10%
> less), i.e. instead of 1.6% + 10¢ per transaction it would be 1.44% +
> 10¢ per transaction. Not sure if this is still the case.
>
> Assuming a 10% discount on fees, a business that did say $100K of credit
> card tranactions (5000 $20 transactions) a month would pay $1940 in
> monthly fees rather than $2100, a savings of $160 per month. Each $20
> transaction would cost 3.2¢ less, each $30 transaction would cost 4.8¢
> less. Not a huge savings, but better than nothing. Since presumably
> almost no business would be patronized based on whether or not they took
> Apple Pay, there has to be an upside to the business to accept it. A
> small savings in transaction costs, plus faster transactions, are two
> upsides.

merchants do not pay any fees for apple pay.

> Maybe that 0.15% in revenue from each transaction is just too small to
> bother about, and putting Apple Pay on Android would create the wrong
> perception. Of course once a merchant is set up for Apple Pay, it's not
> really any more trouble to accept Google Pay as well. Around my area
> it's rare to see a store that accepts Apple Pay but not Google Pay, or
> vice-versa, though the obvious ones exist.

all that's needed is a payment terminal that supports contactless and
have it enabled.

some merchants don't even know they accept apple/google pay.

> Most Android phones about
> $150 have the necessary hardware to do mobile payments, so there's a lot
> of upside potential for mobile payments.

not for apple pay, they don't, and at that level they probably don't
support google pay either.

> Speaking only for myself.

clearly.

others know what they're talking about and don't spew nonsense.

[nospam]

In article <hqidnVZtdLYz_9fG...@giganews.com>, Alan Browne

<bitb...@blackhole.com> wrote:

> >> What made Apple Pay look so great to Americans was the lingering hang on
> >> of magnetic stripe cards in the US that was all but dead in the ROTW
> >> long before Apple Pay. (We've had chipped cards for a long time before
> >> Tap To Pay).
> >
> > no, what makes apple pay great (and not just for looks) is that it's
> > effectively impossible to hack and that it does not provide any user
> > identifiable information to the merchant, not even a name, which makes
> > data mining linked back to the user impossible.
>
> Neither does tap-to-pay other than the CC number. The 3 digit security
> code is not transmitted. Nor the user's name. Nothing the merchant can
> use. And the merchant, transaction to transaction from the same card
> sees different numbers every time...

once again, a stolen card can be used by *anyone*, tap, dip or swipe.

a stolen iphone can't be used for apple pay. it requires the legitimate
owner's fingerprint or face.

also, a card reader ($5-10ish on ebay) can read the chip on the card,
which has that info, and you can be sure that at least some merchants
are keeping that information.

> Finally of course, there is no liability to the card holder nor to the
> merchant for fraudulent charges on compliant systems.

still a hassle.

[nospam]

In article <slrnpkkovt....@Snow.local>, Lewis

<g.k...@gmail.com.dontsendmecopies> wrote:

>
> > apple wanted to offer turn by turn directions, except that google
> > refused to allow others to offer it so that android would have a
> > competitive advantage.
>
> Google was refusing to renew the contract with Apple unless
> they shared the customer data with Google. In exchange, Google offered
> TBT directions. Apple told Google to fuck off.

almost.

google does not allow others to do turn by turn at all.

even today, it's still there:
<https://developers.google.com/maps/terms>
10.4 Restrictions on Unfair Exploitation of the Service and Content.
...
ii No navigation. You will not use the Service or Content for or in
connection with (a) real-time navigation or route guidance; or (b)
automatic or autonomous vehicle control.

apple has the clout to negotiate something beyond the standard terms,
but google insisted on customer data, which could also be used to help
better design android, not just targeted ads.

apple was not interested in that, and for good reason.

> > apple had *no* choice but to find an alternative, and fast.
>
> Or give up their customer's data, which they were unwilling to do.

yep.

> > they are now rebuilding the entire product with their own data so that
> > it does exactly what they want. it's a huge undertaking but they have
> > the resources to do it.
>
> They have been rebuilding it for years, since Apple Maps launched, in
> fact. This is not a new thing they just started, it's taken them years
> to get here.

yep, and it's an ongoing project.

[sms]

On 7/14/2018 1:10 PM, Alan Browne wrote:

> 1) No because it does not have the requisite Apple Pay hardware required
> by Apple Pay's spec.  eg: the Secure Enclave as implemented by Apple.
> More important is how Apple Pay is implemented as an interface to the
> banks - and that will be different than, Google Pay.

Android has had "Secure Enclave" since Marshmallow. Of course there are
still a lot of old Android devices out there that are running older
(<6.0) versions of Android, but probably not very many that also have
NFC. Of course it's not "Secure Enclave as implemented by Apple."

> 2) All that matters to you is if your specific Android phone supports
> tap-to-pay.  Whether that includes your $130 phone, I don't know.  Look
> at its spec - if it supports Google Pay and your bank and cards support
> it then that's all that counts.

Google Pay works with his $130 LG Stylo 3 Plus (which really cost more
than $130 unlocked). BTW, you can't use Google Pay on a rooted Android
phone.

> Nospam is probably on about "the majority of Android devices" and he may
> well be right.  I'm certainly not wasting my time on your trolling
> antics for that.

If he's only talking about the majority of Android devices ever
produced, then he's right, though the same would likely apply to the
majority of iOS devices ever produced.

Of course there are some disposable Android phones still sold by some
carriers such as Tracfone, MetroPCS, Cricket, etc. that while the OS
supports "Secure Enclave" the hardware does not have NFC. Most $150+ new
Android phones support Secure Enclave as well as have NFC, but not all.

[Jolly Roger]

He refuses to acknowledge this objective fact due to his obvious bias.

[Jolly Roger]

On 2018-07-14, nospam <nos...@nospam.invalid> wrote:

> In article <hqidnVZtdLYz_9fG...@giganews.com>, Alan Browne
><bitb...@blackhole.com> wrote:
>
>>>> What made Apple Pay look so great to Americans was the lingering
>>>> hang on of magnetic stripe cards in the US that was all but dead
>>>> in the ROTW long before Apple Pay. (We've had chipped cards for a
>>>> long time before Tap To Pay).
>>>
>>> no, what makes apple pay great (and not just for looks) is that
>>> it's effectively impossible to hack and that it does not provide
>>> any user identifiable information to the merchant, not even a name,
>>> which makes data mining linked back to the user impossible.
>>
>> Neither does tap-to-pay other than the CC number. The 3 digit
>> security code is not transmitted. Nor the user's name. Nothing the
>> merchant can use. And the merchant, transaction to transaction from
>> the same card sees different numbers every time...
>
> once again, a stolen card can be used by *anyone*, tap, dip or swipe.
>
> a stolen iphone can't be used for apple pay. it requires the
> legitimate owner's fingerprint or face.

He has to ignore this fact - he's heavily invested in his slant against
it.

[sms]

On 7/14/2018 1:53 PM, Alan Browne wrote:
> On 2018-07-14 16:37, nospam wrote:
>> In article <ktSdndKxZ7trotfG...@giganews.com>, Alan Browne
>> <bitb...@blackhole.com> wrote:
>>
>>>
>>> What made Apple Pay look so great to Americans was the lingering hang on
>>> of magnetic stripe cards in the US that was all but dead in the ROTW
>>> long before Apple Pay.  (We've had chipped cards for a long time before
>>> Tap To Pay).
>>
>> no, what makes apple pay great (and not just for looks) is that it's
>> effectively impossible to hack and that it does not provide any user
>> identifiable information to the merchant, not even a name, which makes
>> data mining linked back to the user impossible.
>
> Neither does tap-to-pay other than the CC number.  The 3 digit security
> code is not transmitted.  Nor the user's name.  Nothing the merchant can
> use.  And the merchant, transaction to transaction from the same card
> sees different numbers every time...
>
> Finally of course, there is no liability to the card holder nor to the
> merchant for fraudulent charges on compliant systems.

In the U.S., where we have Chip & Signature (but more often Chip with no
signature), Apple Pay and Google Pay are more secure, as long as the
phone has a fingerprint sensor.

In the rest of the world, which uses Chip & Pin, there's no real
advantage in security over Apple Pay and Google Pay in terms of security.

In the U.S., the credit card companies seem to be very much opposed to
Chip & PIN, fearing that it would reduce credit card use. The issuing
banks also seem opposed to it, fearing that it will decrease debit card
use in favor of credit card use.

If you're traveling to Europe, it's very useful to get a credit card
issued by one of the few institutions that are providing Chip & PIN
credit cards.PenFed Credit Union is probably the best option, also
offering 2% cash rebates and no foreign transaction fees.

[nospam]

In article <pie1lh$75t$1...@dont-email.me>, sms

<scharf...@geemail.com> wrote:

> > 1) No because it does not have the requisite Apple Pay hardware required
> > by Apple Pay's spec.  eg: the Secure Enclave as implemented by Apple.
> > More important is how Apple Pay is implemented as an interface to the
> > banks - and that will be different than, Google Pay.
>
> Android has had "Secure Enclave" since Marshmallow.

nope.

android has *support* for a secure enclave, and it predates marshmallow.

whether a particular android device has the necessary hardware is up to
the device maker. google doesn't require it and most do not have it.
generally, it's only the premium models.

for devices that lack the secure enclave, there's host card emulation,
which is not as secure and in some cases, not encrypted (really).

> > Nospam is probably on about "the majority of Android devices" and he may
> > well be right.  I'm certainly not wasting my time on your trolling
> > antics for that.
>
> If he's only talking about the majority of Android devices ever
> produced, then he's right, though the same would likely apply to the
> majority of iOS devices ever produced.

i'm not talking about 'ever produced'.

[nospam]

In article <pie2cj$9to$1...@dont-email.me>, sms

<scharf...@geemail.com> wrote:

>
> In the U.S., where we have Chip & Signature (but more often Chip with no
> signature),

signature is no longer required for most transactions.

> Apple Pay and Google Pay are more secure, as long as the
> phone has a fingerprint sensor.

or face id, which is the case for every device that supports apple pay.

not the case for android, and samsung blocks their face unlock from
being used for any financial transaction because it's not secure
enough.

> In the rest of the world, which uses Chip & Pin, there's no real
> advantage in security over Apple Pay and Google Pay in terms of security.

oh yes there is. significantly so.

> In the U.S., the credit card companies seem to be very much opposed to
> Chip & PIN, fearing that it would reduce credit card use. The issuing
> banks also seem opposed to it, fearing that it will decrease debit card
> use in favor of credit card use.

nope, since banks make more money with a credit card transaction.
they'd love it if you ran everything as credit, while merchants would
rather you didn't.

a pin also adds an extra step to the transaction and another number to
remember. most people would write it on the back of their card.

> If you're traveling to Europe, it's very useful to get a credit card
> issued by one of the few institutions that are providing Chip & PIN
> credit cards.PenFed Credit Union is probably the best option, also
> offering 2% cash rebates and no foreign transaction fees.

barclays cards are pin-preferring.

[Jolly Roger]

On 2018-07-15, nospam <nos...@nospam.invalid> wrote:
> In article <pie1lh$75t$1...@dont-email.me>, sms
><scharf...@geemail.com> wrote:
>
>> > 1) No because it does not have the requisite Apple Pay hardware
>> > required by Apple Pay's spec.  eg: the Secure Enclave as
>> > implemented by Apple. More important is how Apple Pay is
>> > implemented as an interface to the banks - and that will be
>> > different than, Google Pay.
>>
>> Android has had "Secure Enclave" since Marshmallow.
>
> nope.
>
> android has *support* for a secure enclave, and it predates
> marshmallow.
>
> whether a particular android device has the necessary hardware is up
> to the device maker. google doesn't require it and most do not have
> it. generally, it's only the premium models.

Even the models that do actually support it don't fully implement it
across the entire system (if at all) like iOS does. It's a weak joke in
comparison.

[nospam]

In article <fqvicr...@mid.individual.net>, Jolly Roger

<jolly...@pobox.com> wrote:

> >> > 1) No because it does not have the requisite Apple Pay hardware
> >> > required by Apple Pay's spec.  eg: the Secure Enclave as
> >> > implemented by Apple. More important is how Apple Pay is
> >> > implemented as an interface to the banks - and that will be
> >> > different than, Google Pay.
> >>
> >> Android has had "Secure Enclave" since Marshmallow.
> >
> > nope.
> >
> > android has *support* for a secure enclave, and it predates
> > marshmallow.
> >
> > whether a particular android device has the necessary hardware is up
> > to the device maker. google doesn't require it and most do not have
> > it. generally, it's only the premium models.
>
> Even the models that do actually support it don't fully implement it
> across the entire system (if at all) like iOS does. It's a weak joke in
> comparison.

or just put the fingerprint scan in a world-readable unencrypted bmp.

<https://www.theverge.com/2015/8/10/9126027/htc-fingerprint-scanner-vuln
erability-one-max>
...The firm found that the HTC One Max, a nearly two-year-old phone
with a fingerprint reader, kept the fingerprints that it scanned in
an unencrypted, world-readable file; what that translates to is a
file that any app on the device can read or access to get a look at
stored fingerprints ‹ something that could be a real issue if a
malicious app was aware of the flaw.
...
FireEye's report suggests that other phones with fingerprint readers
may have similar problems, though it only names the One Max. The
report also notes that certain phones failed to fully secure their
fingerprint sensor, potentially allowing apps to step in and read
them as a scan was happening. This flaw was present on the One Max,
Samsung's Galaxy S5, and others that FireEye leaves unnamed; all
phones with the flaw were fixed after their manufacturer was alerted
of the issue. "After a thorough review with FireEye, it was found
that all Galaxy S5 users¹ data remain safe," a Samsung representative
said.

i would not be surprised if the 'fix' was to change the permissions to
not be world readable anymore.

[Jolly Roger]

On 2018-07-15, nospam <nos...@nospam.invalid> wrote:

Comical. In comparison, Apple doesn't even store an image of your
fingerprint, and the mathematical representation it does store is inside
the Secure Enclave with an encryption key that is also stored within the
Secure Enclave so that not even someone with root access can read it.
Android "security" is a joke in comparison. A Secure Enclave does you no
good if it isn't used properly to begin with.

[nospam]

In article <fqvlm9...@mid.individual.net>, Jolly Roger

<jolly...@pobox.com> wrote:

> >> Even the models that do actually support it don't fully implement it
> >> across the entire system (if at all) like iOS does. It's a weak joke in
> >> comparison.
> >
> > or just put the fingerprint scan in a world-readable unencrypted bmp.
> >
> ><https://www.theverge.com/2015/8/10/9126027/htc-fingerprint-scanner-vuln
> > erability-one-max>
> > ...The firm found that the HTC One Max, a nearly two-year-old phone
> > with a fingerprint reader, kept the fingerprints that it scanned in
> > an unencrypted, world-readable file; what that translates to is a
> > file that any app on the device can read or access to get a look at

> > stored fingerprints ? something that could be a real issue if a

> > malicious app was aware of the flaw.
> > ...
> > FireEye's report suggests that other phones with fingerprint readers
> > may have similar problems, though it only names the One Max. The
> > report also notes that certain phones failed to fully secure their
> > fingerprint sensor, potentially allowing apps to step in and read
> > them as a scan was happening. This flaw was present on the One Max,
> > Samsung's Galaxy S5, and others that FireEye leaves unnamed; all
> > phones with the flaw were fixed after their manufacturer was alerted
> > of the issue. "After a thorough review with FireEye, it was found

> > that all Galaxy S5 users1 data remain safe," a Samsung representative

> > said.
> >
> > i would not be surprised if the 'fix' was to change the permissions to
> > not be world readable anymore.
>
> Comical.

not the word i would have chosen.

one really has to wonder about a company who would even consider such
an idiotic scheme, let alone actually do it *and* ship the product.

> In comparison, Apple doesn't even store an image of your
> fingerprint, and the mathematical representation it does store is inside
> the Secure Enclave with an encryption key that is also stored within the
> Secure Enclave so that not even someone with root access can read it.

yep. the authentication is done within the secure enclave, but even if
they could somehow extract it, it can't be reversed to a fingerprint.

> Android "security" is a joke in comparison. A Secure Enclave does you no
> good if it isn't used properly to begin with.

yep.

and then there's the fact that apple pay requires os-level support.
it's not an app that can be downloaded.

the suggestion for apple to bring it to android is beyond absurd.

[Jolly Roger]

On 2018-07-15, nospam <nos...@nospam.invalid> wrote:

Indeed. People who make suggestions like that are just showing their
relative ignorance regarding security and hardware and software design.
I guess it's to be somewhat expected to some extent with technology
being put in the hands of the average Joe, but once it turns into a
debate with those who know better, it's a complete farce.

[Arlen Holder]

On 14 Jul 2018 12:37:09 GMT, nospam wrote:

> i said it violates youtube's terms of service, and it does.

You say a lot, nospam, almost all of which is dead wrong.

The NewPipe source code is and has been freely available for years.
New Pipe has been getting better & better & better, over those years.

I'm not a lawyer and neither are you, so I won't "just guess".
What I know are the facts.

*Google has always known exactly what NewPipe does & how it does it.*

Google has more clout than does God himself, in terms of being able to
break NewPipe or to prosecute a lawsuit, even one they know they'll lose.

Show us the facts, nospam.
Where is the legal action against NewPipe developers?

HINT: You "just guessing" that Google is on firm legal grounds is useless,
because you've already proven that your guesses are worse than those of the
monkey.

[Arlen Holder]

On 14 Jul 2018 12:37:12 GMT, nospam wrote:

> no. apple pay is not supported on android, period.
>
> google pay works on *some* android phones but not all of them.
>
> post the model # of this mystery android phone so its specs can be
> checked.
>
> chances are very high that it doesn't have nfc, which would prevent it
> from supporting google pay, never mind apple pay.

Heheheheh...

I love how you responded, nospam, since I already predicted to sms exactly
how you would wiggle out of your statements which are almost always dead
wrong.

Every time you post, you prove me right.

You know full well that I've said a huge number of times, as recently as a
few times today alone, that the el-cheapo $130 LG Stylo 3 Plus is the phone
(but, of course, even though you've responded many times about it, you
"conveniently forget" facts when the time comes for you to wiggle out).

And you know full well that this $130 phone has NFC.

From:
Phablet stocking stuffers: iPhone 7 versus LG Stylo 3 Plus price/performance hardware comparison
<https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/HDI8moW_4Pw[26-50]>

*HARDWARE COMPARISON OF STOCKING STUFFERS: iPhone 7 Plus vs Stylo 3 Plus:*
Price: The Stylo was $130; while the iPhone is ~$670 (~five times more!)
CPU: The Stylo has 8 cores; while the iPhone has only 4 cores
CPU top speed: iPhone is 2.34GHz for 2 cores; Stylo is 1.4GHz for 4 cores
(EDIT: The iPhone throttles to about 1/2 that after a year of use.)
CPU lower speed: iPhone is 1.1GHz for 2 cores; Stylo is 1.1GHz for 4 cores
Storage: Both are 32GB
Expandable: Stylo expands to 2TB; iPhone is missing this key functionality
Screen size: Stylo is 5.7 inches; iPhone is 5.5 inches
Display type: Both are IPS LCD
Pixel density: iPhone is 401ppi; Stylo is 386ppi
Screen resolution: both are the same at full HD 1080x1920 pixels
Main camera: Stylo rear camera is 13MP, while the iPhone 7 is 12MP
Selfie camera: iPhone is 7MP with flash; Stylo is 5MP with flash
Video: both are the same full HD at 1920x1080pixels at 30fps
Wi-Fi: both are the same at 802.11 everything up to ac, dual band
VoLTE: both are the same
*NFC: both have NFC*
Sensors: both have the same stuff
Bands: both have what is needed for the T-Mobile carrier we often use
Bluetooth: both are the same spec at version 4.2
Battery ease: Stylo is removable; while the iPhone 7 is not
Battery capacity: Stylo is 3080mAh, while the iPhone 7 is 2900mAh
RAM: iPhone 7 is 3GB while the Stylo is 2GB
Fingerprint sensor: iPhone 7 is on front; Stylo is on the back
SIM: Both are single nano SIM
Network: Both seem to support the same networks
Stylus: Stylo has a stylus; iPhone 7 is missing this functionality
FM Radio: Stylo has an FM radio; iPhone 7 is missing this functionality
Headphone: Stylo has a courageous jack; iPhone 7 is lost functionality
Wordsize: Both are 64-bit

REFERENCES:
<https://www.gadgetsnow.com/compare-mobile-phones/LG-Stylo-3-Plus-vs-Apple-iPhone-7-Plus>
<https://www.phonearena.com/phones/compare/LG-Stylo-3-Plus,Apple-iPhone-7-Plus/phones/10534%2C9816>
<http://membershipwireless.com/50699/apple-iphone-7-plus-black-32gb/activationtype/new>
<http://membershipwireless.com/52734/stylo-3-plus/activationtype/new>

[Arlen Holder]

On 14 Jul 2018 12:24:38 GMT, Alan Browne wrote:

>> Why does Apple restrict what apps can do?
>
> - Security
> - Simplicity
> - Maintainability

Hi Alan Browne,

These are good answers to the question of why Apple severely restricts the
users' ability to organize the homescreen the way they want to organize it.

Of course, Apple's restrictions mean the iOS user has to "just give up"
constantly (because hundreds of even the simplest things like renaming apps
to make more sense or organizing them in multiple folders just can't be
done on iOS).

> The last two go very much hand in hand as maintainability costs are
> proportional to the square of complexity. (ish - probably Cm ∝ K^2 / 2)
> where Cm is maintenance cost and K is the complexity as defined by
> combinations).

You made the point of security, simplicity, and maintainability, and you
make the point that it vastly decreases the costs (to Apple).

But Apple doesn't pass that cost decrease onto the customers, as, um, er,
I'm sure you're aware that the overall cost of ownership of Apple devices
is, um, er, shall we say, astronomical.

I realize the half-dozen Apple Apologists such as nospam, Jolly Roger,
Lewis, BK@OnRamp, etc., will scream that the "resale value" of their
astronomically priced phones is high, but remember that I bought an entire
handful of LG Stylo 3 Plus phones for far less than the price of a single
iPhone 7 Plus, where each of those LG Stylo 3 Plus phones has far more app
functionality than any iPhone ever made (and where the sales tax alone on
the iPhone, which you never get back, was almost as much as the far more
functional Android phone).

My only point is that Apple isn't passing that cost saving you speak of, to
the customer.

> Attempts include failures.
> Apple's arrogance in this area has cost them dearly.

It's good that you appear to be reasonable in that you realize that all big
companies make big gambles where they fail big.

Apple, to their credit, gambled big early on in smart mobile devices, and
also in the extremely well designed iPod, which is a marvel to behold in
its utter reliability and simplicity.

What's interesting about the iPod is that I had MP3 players from Panasonic
before the dozen or so iPods that I bought, where I bought the first iPod
for a child whose friends had them and I was hooked the moment I explained
how to use it to her.

I was amazed, for example, that the box didn't contain a thick user manual
like the Panasonic did (remember, in those days, user manuals habitually
came with devices).

I had quite a few "encounters" with iTunes though, since, being innocent of
Apple's Orwellian punishments, I was unaware that Apple sent anyone who
tried to do what "they" wanted to do with the iPod, to Room 101.

Once I avoided the iTunes abomination, everything worked exactly as I
wanted it to, where I could copy any MP3 file I had to any iPod I wanted to
put it on from any computer that I happened to be on no matter whom I set
up the iPod for - just like I could with the earlier Panasonic MP3 players,
all without having a sharpened stake shoved up the butt - which is what
iTunes did time and again and which SharePod never did.

> I don't know if Google Maps is the best in class. It's 'my' best, but I
> wouldn't be surprised to find better. But then I don't use it much on
> my phone except at the penultimate part of finding somewhere.

I'm currently writing a cross-platform iOS/Android tutorial for
georeferencing PDF maps so that you can use them in both iOS and Android
location, tracking, and routing freeware.

Hence, you shouldn't be surprised if I tell you I'm as knowledgeable with
map software as any other average user, where, for example, this is the map
folder on a phone I'm currently populating from other random phones (which
is another functionality just not possible on iOS):
<http://img4.imagetitan.com/img.php?image=18_android_maps_01.jpg>

Suffice to say, I was using similar software when it was on laptops
literally on our lap while driving, and then I moved to the dashboard units
like the Garmin StreetPilot III, and then to the nuvi's, magellan, etc.,
and then to Android and then to iOS phones.

My assessment?
Google Maps is, for most things, best in class.

Where Google Maps fails miserably on is in offline use, which is why it's
not on my phone in the first slot (where all my apps are organized by
functionality).

> No, you just put up straw and hope someone punches.

You fail to understand that I ask valid questions.
You may not like the question, so you may consider it a 'straw man'.
But the question is valid for the newsgroup.

> You've come up with a nice obsequious format of late,
> but you're still a troll. Dyed in the wool.

What you seem to have failed to realize is that I am like a mirror in that
I respond to each post in the manner and intent in which I perceive it to
have been offered.

You think I've changed my stripes - but I have *always* responded in like
manner and kind to the presumed intent and tone of the poster.

What you see is the difference in how I treat responses when, for example,
nospam posts his "guesses" (where the monkey does better), since I know
nospam has almost zero helpful intent, and when Jolly Roger posts his
fanatically fabricated iOS imaginations, or when Snit posts his incessant
claims of non-existing iOS functionality, or when Lewis and BK@OnRamp post
their childish drivel.

When you see me responding courteously to sms, you apparently consider that
"obsequious"; but what you don't seem to comprehend is that I respond to
each poster in like manner and kind.

For example, you just called me a troll - which proves you aren't all that
intelligent - because you call me that simply because you don't like that I
happen to know a lot about iOS and Android - where - I happen to mention
the differences in this newsgroup ... which you apparently hate, so, you
call those facts, a troll.

You've never once ever found my facts to be wrong, for example.

[Chris]

Alan Browne <bitb...@blackhole.com> wrote:
>
> Contrary to that Apple Music is a service where the revenue value is in
> delivering the music to any possible platform. It's worth roughly $10B
> per year (depending on who's guesstimating). Also of course the
> platform is already out there (iTunes) - though not on Android...

Despite that Apple music has an official app on Android.

[Arlen Holder]

On 15 Jul 2018 07:31:04 GMT, Arlen Holder wrote:

> I realize the half-dozen Apple Apologists such as nospam, Jolly Roger,
> Lewis, BK@OnRamp, etc., will scream that the "resale value" of their
> astronomically priced phones is high, but remember that I bought an entire
> handful of LG Stylo 3 Plus phones for far less than the price of a single
> iPhone 7 Plus, where each of those LG Stylo 3 Plus phones has far more app
> functionality than any iPhone ever made (and where the sales tax alone on
> the iPhone, which you never get back, was almost as much as the far more
> functional Android phone).

Correction, the sales tax alone on the iPhone is only about *half* the
price of the essentially equivalent Android phone, where there is already a
long thread on the hardware-to-hardware comparison over here:

Phablet stocking stuffers: iPhone 7 versus LG Stylo 3 Plus price/performance hardware comparison
<https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/HDI8moW_4Pw[26-50]>

*HARDWARE COMPARISON OF STOCKING STUFFERS: iPhone 7 Plus vs Stylo 3 Plus:*
Price: The Stylo was $130; while the iPhone is ~$670 (~five times more!)
CPU: The Stylo has 8 cores; while the iPhone has only 4 cores
CPU top speed: iPhone is 2.34GHz for 2 cores; Stylo is 1.4GHz for 4 cores
(EDIT: The iPhone throttles to about 1/2 that after a year of use.)

(EDIT: At least one of the iPhone cores is not available to app programs.)
CPU lower speed: Stylo is 1.1GHz for 4 cores; iPhone is 1.1GHz for 2 cores
Storage: Both are 32GB
Expandable: Stylo up to 2TB; iPhone is completely missing key functionality

Screen size: Stylo is 5.7 inches; iPhone is 5.5 inches
Display type: Both are IPS LCD
Pixel density: iPhone is 401ppi; Stylo is 386ppi
Screen resolution: both are the same at full HD 1080x1920 pixels

Main camera: Stylo is 13MP, while the iPhone 7 is 12MP

Selfie camera: iPhone is 7MP with flash; Stylo is 5MP with flash
Video: both are the same full HD at 1920x1080pixels at 30fps
Wi-Fi: both are the same at 802.11 everything up to ac, dual band
VoLTE: both are the same

NFC: both have NFC

Sensors: both have the same stuff
Bands: both have what is needed for the T-Mobile carrier we often use
Bluetooth: both are the same spec at version 4.2

Battery ease: Stylo is easily removable; while the iPhone 7 is not

Battery capacity: Stylo is 3080mAh, while the iPhone 7 is 2900mAh
RAM: iPhone 7 is 3GB while the Stylo is 2GB

Fingerprint sensor: Both have a fingerprint sensor.

[nospam]

In article <piet7n$4kb$3...@news.mixmin.net>, Arlen Holder

<arlen...@nospam.net> wrote:

> But Apple doesn't pass that cost decrease onto the customers, as, um, er,
> I'm sure you're aware that the overall cost of ownership of Apple devices
> is, um, er, shall we say, astronomical.

nope. apple total cost of ownership is lower.

<https://www.jamf.com/blog/debate-over-ibm-confirms-that-macs-are-535-le
ss-expensive-than-pcs/>
But isnıt it expensive, and doesnıt it overload IT? No. IBM found
that not only do PCs drive twice the amount of support calls, theyıre
also three times more expensive. Thatıs right, depending on the
model, IBM is saving anywhere from $273 - $543 per Mac compared to a
PC, over a four-year lifespan. ³And this reflects the best pricing
weıve ever gotten from Microsoft,² Previn said. Multiply that number
by the 100,000+ Macs IBM expects to have deployed by the end of the
year, and weıre talking some serious savings.

> I realize the half-dozen Apple Apologists such as nospam, Jolly Roger,
> Lewis, BK@OnRamp, etc., will scream that the "resale value" of their
> astronomically priced phones is high, but remember that I bought an entire
> handful of LG Stylo 3 Plus phones for far less than the price of a single
> iPhone 7 Plus, where each of those LG Stylo 3 Plus phones has far more app
> functionality than any iPhone ever made (and where the sales tax alone on
> the iPhone, which you never get back, was almost as much as the far more
> functional Android phone).

nonsense, the stylo is nowhere near as capable as an iphone 7+, which
is why it's so cheap.

and resale value counts. good luck reselling those things. they're
disposable.

> What's interesting about the iPod is that I had MP3 players from Panasonic
> before the dozen or so iPods that I bought, where I bought the first iPod
> for a child whose friends had them and I was hooked the moment I explained
> how to use it to her.

there's nothing to explain. ipods are very easy to use.

> I was amazed, for example, that the box didn't contain a thick user manual
> like the Panasonic did (remember, in those days, user manuals habitually
> came with devices).

it didn't need a thick manual because it was so easy to use and one
major reason why it was so insanely popular.

>
> > I don't know if Google Maps is the best in class. It's 'my' best, but I
> > wouldn't be surprised to find better. But then I don't use it much on
> > my phone except at the penultimate part of finding somewhere.
>
> I'm currently writing a cross-platform iOS/Android tutorial for
> georeferencing PDF maps so that you can use them in both iOS and Android
> location, tracking, and routing freeware.

except that like your other tutorials, you have absolutely no idea what
you're doing, therefore you rely on others to teach you so that you can
'write' it.

an ongoing thread in the gps & win10 newsgroups is a perfect example.

<pidl1f$n08$1...@gioia.aioe.org>

> You've never once ever found my facts to be wrong, for example.

everyone does, on a daily basis.

[nospam]

In article <piet7k$4kb$1...@news.mixmin.net>, Arlen Holder

<arlen...@nospam.net> wrote:

>
> > i said it violates youtube's terms of service, and it does.
>
> You say a lot, nospam, almost all of which is dead wrong.

nope.

<https://www.youtube.com/static?template=terms>
5. Your Use of Content
In addition to the general restrictions above, the following
restrictions and conditions apply specifically to your use of Content.
...
B Content is provided to you AS IS. You may access Content for your
information and personal use solely as intended through the provided
functionality of the Service and as permitted under these Terms of
Service. You shall not download any Content unless you see a
łdownload˛ or similar link displayed by YouTube on the Service for
that Content. You shall not copy, reproduce, distribute, transmit,
broadcast, display, sell, license, or otherwise exploit any Content
for any other purposes without the prior written consent of YouTube
or the respective licensors of the Content. YouTube and its licensors
reserve all rights not expressly granted in and to the Service and
the Content.

note this sentence:
You shall not download any Content unless you see a łdownload˛ or
similar link displayed by YouTube on the Service for that Content.

*that* is why newpipe is not available on the play store.

[nospam]

In article <pif2k6$db5$1...@news.mixmin.net>, Arlen Holder

<arlen...@nospam.net> wrote:

> Correction, the sales tax alone

irrelevant.

[Lewis]

In message <pie1lh$75t$1...@dont-email.me> sms <scharf...@geemail.com> wrote:
> On 7/14/2018 1:10 PM, Alan Browne wrote:

>> 1) No because it does not have the requisite Apple Pay hardware required
>> by Apple Pay's spec.  eg: the Secure Enclave as implemented by Apple.
>> More important is how Apple Pay is implemented as an interface to the
>> banks - and that will be different than, Google Pay.

> Android has had "Secure Enclave" since Marshmallow.

Not really, since a secure enclave is not a software feature, it's
hardware.

> Of course there are still a lot of old Android devices out there that
> are running older (<6.0) versions of Android, but probably not very
> many that also have NFC. Of course it's not "Secure Enclave as
> implemented by Apple."

It's not secure at all.

> Google Pay works with his $130 LG Stylo 3 Plus (which really cost more
> than $130 unlocked). BTW, you can't use Google Pay on a rooted Android
> phone.

Because it's not actually secure.

>> Nospam is probably on about "the majority of Android devices" and he may
>> well be right.  I'm certainly not wasting my time on your trolling
>> antics for that.

> If he's only talking about the majority of Android devices ever
> produced, then he's right, though the same would likely apply to the
> majority of iOS devices ever produced.

The vast majority of android devices *in use* including some pretty
recent devices do not support Google Pay.

> Of course there are some disposable Android phones still sold by some
> carriers such as Tracfone, MetroPCS, Cricket, etc. that while the OS
> supports "Secure Enclave" the hardware does not have NFC. Most $150+ new
> Android phones support Secure Enclave as well as have NFC, but not all.

Could be, that has not been my impression, but I do not really pay much
attention to Android.

I did explain to a friend of mine recently just HOW Facebook (and any
other company) got call logs and message logs by simply requesting
access to contacts. She's switching to iOS this fall when the new phones
come out.

As she said, "I don't have to time to try to figure out what the latest
android fuck-me feature is."

--
@mdhughes: One of the few regrets I have about lawn-less apartments:
Shallow graves are so much harder to come by.

[sms]

On 7/14/2018 7:20 PM, Jolly Roger wrote:

>> the suggestion for apple to bring it to android is beyond absurd.
>
> Indeed. People who make suggestions like that are just showing their
> relative ignorance regarding security and hardware and software design.
> I guess it's to be somewhat expected to some extent with technology
> being put in the hands of the average Joe, but once it turns into a
> debate with those who know better, it's a complete farce.

No one is suggesting to bring any kind of mobile payment to non-secure
phones.

But remember, the highest-rated phone for security is actually an
Android model (the iPhone X is 2nd), but below 2nd place there are many
highly-secure and sufficiently secure Android models.

You don't understand what is involved in developing secure applications
for different platforms.

[sms]

On 7/15/2018 5:16 AM, Lewis wrote:
> In message <pie1lh$75t$1...@dont-email.me> sms <scharf...@geemail.com> wrote:
>> On 7/14/2018 1:10 PM, Alan Browne wrote:
>
>>> 1) No because it does not have the requisite Apple Pay hardware required
>>> by Apple Pay's spec.  eg: the Secure Enclave as implemented by Apple.
>>> More important is how Apple Pay is implemented as an interface to the
>>> banks - and that will be different than, Google Pay.
>
>> Android has had "Secure Enclave" since Marshmallow.
>
> Not really, since a secure enclave is not a software feature, it's
> hardware.

Actually it's both hardware and firmware. Not every model has had the
hardware of course, only higher-end models.

[Alan Browne]

On 2018-07-14 18:10, sms wrote:
> On 7/14/2018 9:45 AM, Alan Browne wrote:
>
> <snip>
>
>> But that's because, unlike the US, tap to pay has been here for a long
>> time and widely so.  Very secure.  Of course you'll say Apple Pay is
>> more so - but for the difference it actually makes no difference v.
>> tap-to-pay.

>
> One article stated that the percentage fee was slightly less for Apple
> Pay transactions versus swiped credit card transactions  (up to 10%
> less), i.e. instead of 1.6% + 10¢ per transaction it would be 1.44% +
> 10¢ per transaction. Not sure if this is still the case.
>
> Assuming a 10% discount on fees, a business that did say $100K of credit
> card tranactions (5000 $20 transactions) a month would pay $1940 in
> monthly fees rather than $2100, a savings of $160 per month. Each $20
> transaction would cost 3.2¢ less, each $30 transaction would cost 4.8¢
> less. Not a huge savings, but better than nothing. Since presumably
> almost no business would be patronized based on whether or not they took
> Apple Pay, there has to be an upside to the business to accept it. A
> small savings in transaction costs, plus faster transactions, are two
> upsides.
>

> Maybe that 0.15% in revenue from each transaction is just too small to
> bother about, and putting Apple Pay on Android would create the wrong
> perception. Of course once a merchant is set up for Apple Pay, it's not
> really any more trouble to accept Google Pay as well. Around my area
> it's rare to see a store that accepts Apple Pay but not Google Pay, or

> vice-versa, though the obvious ones exist. Most Android phones about

> $150 have the necessary hardware to do mobile payments, so there's a lot
> of upside potential for mobile payments.

First off, per my friend, there's no "rate" advantage to using Apple Pay
for the merchant for card brand. Some are high (VISA platinum, MC
whatever) and some are low. Debit card transactions are the least
costly (fixed fee of about 5 cents) since his transaction values are
pretty high on average. He sees about a dozen different rates (by card
type) on his statements each month. There are several MC and several
VISA rates (he refuses to allow Amex).

There are other transaction based fees the merchant sees, but this is
more complex.

And finally many fixed monthly fees.

Tap to pay is just as fast as Apple Pay. It is secure.

Chipped card pay is slower. It is secure.

Some, like nospam will shout loudly "Apple Pay is more secure". But it
does not matter at all, not one bit, to the merchant or the customer
since both are not liable for fraud with these transactions.

The merchant is potentially liable for magnetic card or phoned in card
numbers.

Anyway I'll ask my friend for more detail and see if he's willing to dig
into it or give me a statement to look at.

--
"2/3 of Donald Trump's wives were immigrants. Proof that we
need immigrants to do jobs that most Americans wouldn't do."
- unknown protester

[Alan Browne]

On 2018-07-14 18:38, nospam wrote:
> In article <P5mdnc3jGvAb_dfG...@giganews.com>, Alan Browne

> <bitb...@blackhole.com> wrote:
>
>>>> What made Apple Pay look so great to Americans was the lingering hang
>>>> on of magnetic stripe cards in the US that was all but dead in the
>>>> ROTW long before Apple Pay.
>>>

>>> Nope. It's still faster, more convenient, and more secure than chipped
>>> cards, which the majority of Americans use today. You don't get to tell
>>> Americans what we fucking like about Apple Pay. You can deny it all you
>>
>> Whiner. Fact is we had chipped cards AND tap to pay LONG before the US.
>>
>> So any advantage of Apple Pay presented as thin, watery stuff.
>
> nope.
>
> apple pay is faster and significantly more secure than chip cards.

You keep saying that. And I keep replying: We've had tap-to-pay for a
long time here, long before Apple Pay and it is just as fast (or as
slow) as Apple Pay depending on the merchant terminal.

eg: Where I usually get gas, tap-to-pay (or Apple Pay) is lightning
fast. Where I usually buy beer, it's variable (quick to 3 or 4 seconds).

And I keep replying that as far as the merchant and customer are
concerned, fraud is not their liability where chip or Tap-to-pay is
concerned. You seem immune to these facts.

So stop screaming about chip. Rarely use it 'cause I don't have to.

[Alan Browne]

On 2018-07-14 18:38, nospam wrote:

> In article <hqidnVZtdLYz_9fG...@giganews.com>, Alan Browne

> <bitb...@blackhole.com> wrote:
>
>>>> What made Apple Pay look so great to Americans was the lingering hang on
>>>> of magnetic stripe cards in the US that was all but dead in the ROTW

>>>> long before Apple Pay. (We've had chipped cards for a long time before

>>>> Tap To Pay).
>>>
>>> no, what makes apple pay great (and not just for looks) is that it's
>>> effectively impossible to hack and that it does not provide any user
>>> identifiable information to the merchant, not even a name, which makes
>>> data mining linked back to the user impossible.
>>
>> Neither does tap-to-pay other than the CC number. The 3 digit security
>> code is not transmitted. Nor the user's name. Nothing the merchant can
>> use. And the merchant, transaction to transaction from the same card
>> sees different numbers every time...
>

> once again, a stolen card can be used by *anyone*, tap, dip or swipe.

And again (as you reply above the whole reply): No liability for customer.

And while a stolen iPhone won't work (1 in 10,000 chance it will) for
tap to pay, an iPhone forgotten at home or completely discharged does
not work at all.

Cards always work and I always have my wallet with me because it holds
other cards I must have with me: driver's license, car insurance, car
registration, medical insurance (gov't + private) and various other
things - even a couple $20's.

[Alan Browne]

On 2018-07-14 18:38, nospam wrote:

> In article <pidscs$aka$1...@dont-email.me>, sms

> <scharf...@geemail.com> wrote:
>
>>
>> One article stated that the percentage fee was slightly less for Apple
>> Pay transactions versus swiped credit card transactions (up to 10%
>> less), i.e. instead of 1.6% + 10¢ per transaction it would be 1.44% +
>> 10¢ per transaction. Not sure if this is still the case.
>>
>> Assuming a 10% discount on fees, a business that did say $100K of credit
>> card tranactions (5000 $20 transactions) a month would pay $1940 in
>> monthly fees rather than $2100, a savings of $160 per month. Each $20
>> transaction would cost 3.2¢ less, each $30 transaction would cost 4.8¢
>> less. Not a huge savings, but better than nothing. Since presumably
>> almost no business would be patronized based on whether or not they took
>> Apple Pay, there has to be an upside to the business to accept it. A
>> small savings in transaction costs, plus faster transactions, are two
>> upsides.
>

> merchants do not pay any fees for apple pay.

Want to bet on that?

[Alan Browne]

On 2018-07-14 19:40, sms wrote:
> On 7/14/2018 1:10 PM, Alan Browne wrote:
>
>> 1) No because it does not have the requisite Apple Pay hardware
>> required by Apple Pay's spec.  eg: the Secure Enclave as implemented
>> by Apple. More important is how Apple Pay is implemented as an
>> interface to the banks - and that will be different than, Google Pay.
>

> Android has had "Secure Enclave" since Marshmallow. Of course there are

> still a lot of old Android devices out there that are running older
> (<6.0) versions of Android, but probably not very many that also have

> NFC. Of course it's not "Secure Enclave as implemented by Apple."

Which was the salient point.

>> 2) All that matters to you is if your specific Android phone supports
>> tap-to-pay.  Whether that includes your $130 phone, I don't know.
>> Look at its spec - if it supports Google Pay and your bank and cards
>> support it then that's all that counts.

>
> Google Pay works with his $130 LG Stylo 3 Plus (which really cost more
> than $130 unlocked). BTW, you can't use Google Pay on a rooted Android
> phone.

"rooted"? Do you mean like a jailbreaked iPhone? Then I hope it
doesn't work as it would likely present all sorts of security issues.

[Alan Browne]

On 2018-07-14 19:46, Jolly Roger wrote:
> On 2018-07-14, nospam <nos...@nospam.invalid> wrote:
>> In article <P5mdnc3jGvAb_dfG...@giganews.com>, Alan Browne

>> <bitb...@blackhole.com> wrote:
>>
>>>>> What made Apple Pay look so great to Americans was the lingering hang
>>>>> on of magnetic stripe cards in the US that was all but dead in the
>>>>> ROTW long before Apple Pay.
>>>>

>>>> Nope. It's still faster, more convenient, and more secure than chipped
>>>> cards, which the majority of Americans use today. You don't get to tell
>>>> Americans what we fucking like about Apple Pay. You can deny it all you
>>>
>>> Whiner. Fact is we had chipped cards AND tap to pay LONG before the US.
>>>
>>> So any advantage of Apple Pay presented as thin, watery stuff.
>>
>> nope.
>>
>> apple pay is faster and significantly more secure than chip cards.
>

> He refuses to acknowledge this objective fact due to his obvious bias.

Not at all. My point has always been that we've had:

READ THIS CAREFULLY: tap-to-pay GOT THAT?

for far longer than the US and long before Apple Pay - so its emergence
in the market was not all that hot a thing for speed reasons.

You (and nospam) always reply " but chip is slow!". Who cares?
Whenever a terminal is tap-to-pay I use that. And if it isn't then
Apple Pay won't work there either.

I never said chip transactions are quicker - and the real slow down is
not the technical speed but the finger speed of the old lady in line who
can't get her pin right...

[Alan Browne]

On 2018-07-14 19:47, Jolly Roger wrote:
> On 2018-07-14, nospam <nos...@nospam.invalid> wrote:

>> In article <hqidnVZtdLYz_9fG...@giganews.com>, Alan Browne

>> <bitb...@blackhole.com> wrote:
>>
>>>>> What made Apple Pay look so great to Americans was the lingering
>>>>> hang on of magnetic stripe cards in the US that was all but dead

>>>>> in the ROTW long before Apple Pay. (We've had chipped cards for a
>>>>> long time before Tap To Pay).
>>>>
>>>> no, what makes apple pay great (and not just for looks) is that
>>>> it's effectively impossible to hack and that it does not provide
>>>> any user identifiable information to the merchant, not even a name,
>>>> which makes data mining linked back to the user impossible.
>>>
>>> Neither does tap-to-pay other than the CC number. The 3 digit
>>> security code is not transmitted. Nor the user's name. Nothing the
>>> merchant can use. And the merchant, transaction to transaction from
>>> the same card sees different numbers every time...
>>
>> once again, a stolen card can be used by *anyone*, tap, dip or swipe.
>>

>> a stolen iphone can't be used for apple pay. it requires the
>> legitimate owner's fingerprint or face.
>
> He has to ignore this fact - he's heavily invested in his slant against
> it.

I have no slant against it. I have a slant against the idea that it's a
be-all and end all.

The customer has 0 liability for stolen cards. It's a non issue.

[Alan Browne]

On 2018-07-14 19:52, sms wrote:
> On 7/14/2018 1:53 PM, Alan Browne wrote:
>> On 2018-07-14 16:37, nospam wrote:
>>> In article <ktSdndKxZ7trotfG...@giganews.com>, Alan Browne

>>> <bitb...@blackhole.com> wrote:
>>>
>>>>
>>>> What made Apple Pay look so great to Americans was the lingering
>>>> hang on
>>>> of magnetic stripe cards in the US that was all but dead in the ROTW
>>>> long before Apple Pay.  (We've had chipped cards for a long time before
>>>> Tap To Pay).
>>>
>>> no, what makes apple pay great (and not just for looks) is that it's
>>> effectively impossible to hack and that it does not provide any user
>>> identifiable information to the merchant, not even a name, which makes
>>> data mining linked back to the user impossible.
>>
>> Neither does tap-to-pay other than the CC number.  The 3 digit
>> security code is not transmitted.  Nor the user's name.  Nothing the
>> merchant can use.  And the merchant, transaction to transaction from
>> the same card sees different numbers every time...
>>

>> Finally of course, there is no liability to the card holder nor to the
>> merchant for fraudulent charges on compliant systems.

>
> In the U.S., where we have Chip & Signature (but more often Chip with no

> signature), Apple Pay and Google Pay are more secure, as long as the

> phone has a fingerprint sensor.
>

> In the rest of the world, which uses Chip & Pin, there's no real
> advantage in security over Apple Pay and Google Pay in terms of security.
>

> In the U.S., the credit card companies seem to be very much opposed to
> Chip & PIN, fearing that it would reduce credit card use. The issuing
> banks also seem opposed to it, fearing that it will decrease debit card

> use in favor of credit card use.

Banks would prefer you use credit cards as they make money on interest
for those who don't pay up at the end of the month.

The issue in the US is that there are THOUSANDS of banks and it is
expensive to roll out new card technologies. In Canada where most
people bank in 7 large banks it's all but a non-issue. Why Canadian
banks were quick to adopt chip and then tap-to-pay.

>
> If you're traveling to Europe, it's very useful to get a credit card
> issued by one of the few institutions that are providing Chip & PIN
> credit cards.PenFed Credit Union is probably the best option, also
> offering 2% cash rebates and no foreign transaction fees.

No issue here - I don't remember when my cards were not chipped. (Well,
maybe Amex was slow...)

[Alan Browne]

On 2018-07-15 03:31, Arlen Holder wrote:

> These are good answers to the question of why Apple severely restricts the
> users' ability to organize the homescreen the way they want to organize it.

Enough trolling from you, yet another one in the plonk box until your
next idiotic nym comes along...

[Alan Browne]

Well, shows you how much I don't pay attention to Android.

[JF Mezei]

>> Perhaps Apple Pay should be offered on other platforms as well.


Apple Pay is special in that it relies in hardware such as the secure
enclave and secure enclosure which are isolated from the CPU.

You couldn't implement that level of security on non iPhone devices
which lack these hardware components.

The secure enclosure runs a fairly standard Oracle JAVA applet provided
by the card issuer to drive the NFC communications/transation. It is the
functional equivalent to a real card with basically the same JAVA
software running from Oracle (forget the commercial name, but it is a
product sold by Oracle to banks)

[JF Mezei]

On 2018-07-14 11:05, Alan Browne wrote:

> about 86% Android to 13% iOS (worldwide). So Apple's "influence" would
> be much larger if they deployed Apple Pay to Android.

To a merchant, whether a customer uses any phone or any card makes no
difference. Bring thing near POS, POS terminal goes "beep" and
transction done.

There is no advantage to Apple making Apple Pay available on hardware it
doesn't control such as Android phone. None. Nada. And since Apple has
no pre-existing relationship with an Android user (such as Apple ID,
software/Music purchase history), the onboarding process where the user
requests a credit card be loaded on his/her phone by his/her bank would
not be accompanied with that additional info which Apple provides when
you on-board on an iPhone.


Just because the USA payments system is fucked up and some POS terminals
gets an "apple pay" sticker (which doesn't garantee it will work)
doesn't mean Apple should roll out Apple Pay outside its own secure
ecosystem.

The "Apple Pay" stickers on POS terminals is meaningless. It just means
it is a contactless terminal that can talk to NFC enabled "cards".
Because the USA hasn't adopted a single standard, it becomes a mismatch
of incompatible chip/signature, chip/pin, magstripe, and NFC
transactions which still transmit the CVM to the POS who can still
reject the card as incompatible despite using an iPhone on a POS
terminal with the Apple Pay sticker.


Outside the USA where there is a world standard, any card (whether
platsic or on a phone) works.

[JF Mezei]

On 2018-07-14 11:20, sms wrote:

> Apple is doing a much better job or marketing Apple Pay, while Google
> just seemed to do it to copy Apple. A couple of months ago I was in
> downtown Palo Alto and merchants were offering big discounts to Apple
> Pay users.


How does that work? you tell cashier you will use Apple Pay and she
gives you discount before you actually used Apple Pay?

[sms]

On 7/14/2018 9:09 AM, Alan Browne wrote:

<snip>

> Contrary to that Apple Music is a service where the revenue value is in
> delivering the music to any possible platform.  It's worth roughly $10B
> per year (depending on who's guesstimating).  Also of course the
> platform is already out there (iTunes) - though not on Android...

Think about collecting 0.15% (0.0015 x the total of credit card
purchases (made in-store)), and it not being a paid subscription
service, but something most people do on a daily basis.

Personally, our credit card expenses, in places where it would be
possible to pay with "Tap & Pay," if available, are about $12K per year
(the actual credit card purchases are much higher, but are automatic
payments or online purchases).

$12,000 * 0.0015= $18 per year revenue for Mobile Payment providers
(assuming both Google Pay and Apple Pay collect about the same
percentage). I expect that for most middle class families the numbers
are similar or higher. $18 per year, per credit card using family,
would be a lot of revenue to go after when it costs almost nothing to
collect.

But the reality is, that at this point in time, we could not spend much
of that $12,000 with Google Pay or Apple Pay. The issue with mobile
payments is that so many major retailers don't accept anything other
than Samsung Pay (by default since it works differently than Apple Pay
or Google Pay), credit cards, or cash.

Costco, Walmart, Target, Home Depot, Lowe's etc. don't accept Google Pay
or Apple Pay
<https://ios.gadgethacks.com/how-to/which-stores-accept-apple-pay-always-up-date-list-0158076/>.
These companies have negotiated extremely low credit card fees,
especially for their store-branded Visa and Mastercard cards. While
small businesses don't pay their processors more for mobile payments,
it's because the higher fees cover that extra cost. The larger
businesses would have to cover the extra cost, plus they'd have less
people using their store-branded cards.

You talk about the $100 per year for Apple Music? How did you come up
with that? For the music services, data about Apple music isn't
available, but using Spotify, the average number of songs streamed per
user per year is 18,000 (based on an average 3 minutes per song) and the
cost paid to rights holders is between 6/10 an 9/10 of one cent per
song. That's $108 per year paid to rights holders (using 6/10 of a
cent). How many Spotify users are paying $9.99 per month? Many Spotify
users use the free version, many are on family plans or student plans
that cost less than the regular $9.99 per month. How can Spotify make
money? Is the advertising on the free version sufficient to cover costs?
The answer is that just like Uber, Twitter, etc., they don't make money,
they have investors that are subsidizing the losses in hope of a future
payoff. I know that on Pandora's free version, the app periodically
pauses the music asks if you are still listening, because many people
just leave it going all day without being there, but I don't know if the
other music services do the same thing.

[sms]

I believe so. Some restaurants were offering 10% off. One place, Pizza
My Heart, was selling slices for $1 if paid for with Apple Pay. We did
not use Apple Pay. My wife's work iPhone was with her, but she has never
set it up for Apple Pay. She's not supposed to use it for anything
except work stuff.

[JF Mezei]

On 2018-07-14 14:27, Alan Browne wrote:

> QUOTE FROM SAME ARTICLE:
> merchants and others who have partnered with Apple say that Apple Pay is
> accounting for 90 percent of all mobile contactless transactions
> globally in markets where it’s available.
> END QUOTE

Only in the USA would merchants partner with Apple to support a credit
card standard.

Elsewhere, merchants haven't had to lift a finger to support Apple Pay
because Apple Pay is compatible with standard debit/credit cards when
near a POS terminal.

If bansk don't ussre NFC cards, and the only NFC devices out there are
iPhones, then of course, those stores who install NFC capable terminals
will see iPhones as vast majority of NFC transactions. But that would be
empirical data because a store wouldn't know if a transation was done
from a phone or a card. It only knows it was contactless vs chip/pin vs
chip/signature.

[JF Mezei]

On 2018-07-14 16:10, Alan Browne wrote:

> 1) No because it does not have the requisite Apple Pay hardware required
> by Apple Pay's spec. eg: the Secure Enclave as implemented by Apple.
> More important is how Apple Pay is implemented as an interface to the
> banks - and that will be different than, Google Pay.

The secure enclave is only used to validate authentication, and keep a
"valid" flag for the Apple Pay cards. The actual data for the payments
is in the Secure Enclosure, a separate processor that runs a JAVA app
with its own storage. This processor is actually pretty standard and
likely not different than what is on Android (and not different from
what is in a normal chiP/pin card).

The "value added" part is that the authentication to enable Apple Pay
transaction is superior because of the Secure Enclave which can't be
hacked.


In terms of on-boarding, it doesn't rely on any special iPhone hardware
as it is more of a standard app with data exchances between you, Apple
and your bank. Theoretically, it could be made to work on Android
phones, with the caveat that the "OK to onboard" payload from the bank
would need code tailopred to that specific phone depending on how it
stores the credit card data during onboarding process.

[sms]

On 7/15/2018 7:53 AM, JF Mezei wrote:
> On 2018-07-14 11:05, Alan Browne wrote:
>
>> about 86% Android to 13% iOS (worldwide). So Apple's "influence" would
>> be much larger if they deployed Apple Pay to Android.
>
> To a merchant, whether a customer uses any phone or any card makes no
> difference. Bring thing near POS, POS terminal goes "beep" and
> transction done.

Actually there's a big difference. To smaller businesses the
transactions are faster. That's a positive difference because it can
reduce labor costs slightly.

To big businesses there are some major disadvantages to accepting Google
Pay or Apple Pay, which is why stores like Walmart, Target, Costco, Home
Depot, etc., don't accept it. These stores heavily promote their own
credit cards because they've negotiated extremely low fees with the card
issuer. Costco pays 0.4% for Costco purchases with the Costco Citibank
Visa so neither Costco nor Citibank is going to absorb another 9.15%
going to Google or Apple. They've also negotiated very low fees for
non-store-affiliated credit cards. Small merchants are paying between
1.6% and 3% depending on the processor and the type of card.

No Google Pay or Apple Pay user is going to put in every store's credit
card unless there is a significant advantage. I have ONE credit card
stored with Google Pay. I'm not going to add six different cards and
select between them depending on which store I'm going to. Costco makes
it convenient to use their own Visa card by combining it with the
membership card, though personally I use a Visa card with a 3% rebate,
not the Citibank card.

> There is no advantage to Apple making Apple Pay available on hardware it
> doesn't control such as Android phone. None. Nada.

The advantage would be the revenue from purchases. It's not none or
nada. It's not tens of billions dollars per year in revenue, but it
would be hundreds of millions. Is the purpose of Google Pay and Apple
Pay to generate revenue or is it to build loyalty to a specific ecosystem?

[JF Mezei]

On 2018-07-14 19:40, sms wrote:

> Android has had "Secure Enclave" since Marshmallow.

On iPhones, the Secure Enclave is a separate processor with its own
storage and RAM. It has a limited set of communbicatiosn capabilities
with the CPU and its RAM. So no app on the iPhone, no matter how
privileged it is, can access the content of the Secure Enclave's storage.

Having a software based "Secure Enclave" on Android doesn't provide
anmywhere near the same level of security since privileged apps can
access that storage.

[JF Mezei]

On 2018-07-14 20:18, nospam wrote:

> signature is no longer required for most transactions.

Doesn't matter. A normal (non USA) card whose CVM doesn't have an entry
to accept chip/signature will buzz "incompatible" when talking to a
chip/signature terminal in USA. (chip/signature is really "chip, no
authentication" from the computer/software point of view.

> a pin also adds an extra step to the transaction and another number to
> remember. most people would write it on the back of their card.

Funny how it is not a problem in countries your president qualifies as
"shithole countries". Could americans be less smart than people in those
countries ?

[sms]

On 7/15/2018 6:49 AM, Alan Browne wrote:

<snip>

> Banks would prefer you use credit cards as they make money on interest
> for those who don't pay up at the end of the month.

Perhaps. They still collect fees on debit cards and the bank keeps the
money on chip and pin transaction. Plus consumers lose the consumer
protections when using a debit card.

>> If you're traveling to Europe, it's very useful to get a credit card
>> issued by one of the few institutions that are providing Chip & PIN
>> credit cards.PenFed Credit Union is probably the best option, also
>> offering 2% cash rebates and no foreign transaction fees.
>
> No issue here - I don't remember when my cards were not chipped.  (Well,
> maybe Amex was slow...)

The U.S. cards are all chipped, but almost none are set up to use a PIN.
When you use one in a restaurant or hotel in Europe you have to still
sign. Since the portable terminals they bring to your table are often
not equipped for a signature, it's time consuming and you have to let
your card be taken.

For some purchases, you can't make them without a Chip & PIN card, such
as buying tickets from a machine at a train station, and not all
stations are attended.

<https://www.creditcards.com/credit-card-news/which-us-issuers-offer-chip-and-pin-card.php>

Look for a chip & pin card with no annual fee, at least a 2% cash
rebate, and no foreign transaction fees.

[JF Mezei]

On 2018-07-14 21:43, nospam wrote:

> yep. the authentication is done within the secure enclave, but even if
> they could somehow extract it, it can't be reversed to a fingerprint.

The danger isn't extracting a fingerprint. It is fooling the phone into
accepting a fingerprint other than the one recorded. On iPhones, the
ribbon cable between the fingerprint sensor and CPU chip carries
encrypted data which only the secure enclave inside that CPU chip has
the keys to decrypt. So it is next to impossible to inject data into
the stream since you don't have the encruption keys that will generate a
stream which secure enclave will accept/decrypt.

[JF Mezei]

On 2018-07-15 11:28, sms wrote:

> Actually there's a big difference. To smaller businesses the
> transactions are faster. That's a positive difference because it can
> reduce labor costs slightly.

tap/pay transactions done by a phone or a card are done in exactly the
same amount of time. The timing of the "beep" is in the EMV tap/pay
standards. The time to wait for authorisation from bank is exactly the
same since it is the same process.

[Alan Browne]

On 2018-07-15 10:57, sms wrote:
> On 7/14/2018 9:09 AM, Alan Browne wrote:
>
> <snip>
>
>> Contrary to that Apple Music is a service where the revenue value is
>> in delivering the music to any possible platform.  It's worth roughly
>> $10B per year (depending on who's guesstimating).  Also of course the
>> platform is already out there (iTunes) - though not on Android...
>
> Think about collecting 0.15% (0.0015 x the total of credit card
> purchases (made in-store)), and it not being a paid subscription
> service, but something most people do on a daily basis.

I wrote further up that Apple probably don't want to incentivize Android
users with this service just to score a few more $. Further, in the
higher value markets (North America, Europe, parts of Asia) the
predominant smartphone is iPhone. Top down is better than bottom up.

Apple's drive is to incentivize people towards its products and
services. Music satisfies that as it is essentially a "cloud" service.

Apple Pay isn't a cloud service - except perhaps on the fringes of the
"Wallet" app.

In other parts of this thread things like Apple Pay security are
discussed as implemented in large part in iPhone hardware (in part, the
Secure Enclave and Apple's implementation of it and things like
fingerprint recognition and face recognition. Given the plethora of
Android hardware variants, Apple would not want to go near that morass
while promising a security level similar to iPhone.

Apple thinks different and rarely try to encompass all possibilities -
quite the opposite.

[Alan Browne]

On 2018-07-15 11:10, JF Mezei wrote:
> On 2018-07-14 14:27, Alan Browne wrote:
>
>> QUOTE FROM SAME ARTICLE:
>> merchants and others who have partnered with Apple say that Apple Pay is
>> accounting for 90 percent of all mobile contactless transactions
>> globally in markets where it’s available.
>> END QUOTE
>
> Only in the USA would merchants partner with Apple to support a credit
> card standard.

Nothing to do with what I wrote above. At all.

>
> Elsewhere, merchants haven't had to lift a finger to support Apple Pay
> because Apple Pay is compatible with standard debit/credit cards when
> near a POS terminal.

Irrelevant. Merchants in the US didn't need to lift a finger either as
long as they had tap-to-pay terminals. If they didn't then they could
get those terminals. I'm sure it's not cheap.

[sms]

On 7/15/2018 6:34 AM, Alan Browne wrote:
> On 2018-07-14 18:38, nospam wrote:
>> In article <pidscs$aka$1...@dont-email.me>, sms
>> <scharf...@geemail.com> wrote:
>>
>>>
>>> One article stated that the percentage fee was slightly less for Apple
>>> Pay transactions versus swiped credit card transactions  (up to 10%
>>> less), i.e. instead of 1.6% + 10¢ per transaction it would be 1.44% +
>>> 10¢ per transaction. Not sure if this is still the case.
>>>
>>> Assuming a 10% discount on fees, a business that did say $100K of credit
>>> card tranactions (5000 $20 transactions) a month would pay $1940 in
>>> monthly fees rather than $2100, a savings of $160 per month. Each $20
>>> transaction would cost 3.2¢ less, each $30 transaction would cost 4.8¢
>>> less. Not a huge savings, but better than nothing. Since presumably
>>> almost no business would be patronized based on whether or not they took
>>> Apple Pay, there has to be an upside to the business to accept it. A
>>> small savings in transaction costs, plus faster transactions, are two
>>> upsides.
>>
>> merchants do not pay any fees for apple pay.
>
> Want to bet on that?

LOL, you're splitting hairs.

There are fees, but they are all bundled into the merchant's fees
charged by the payment processors. Are the fees set at a rate that takes
into account the small extra expense for Google Pay's and Apple Pay's
cut? Of course, but you'll never know what that difference is.

Why do you think large retailers like Costco don't accept mobile
payments? They've negotiated extremely low fees with their credit card
issuers, and an additional 0.15% would be a significant hit when you're
only paying 0.4% to begin with. But when the fee is 1.6% to 3% that
extra 0.15% is not so significant.

What I was referring to in my earlier post, which nospam did not read
for comprehension, was a report that said that the merchant fees were
LESS for tap & pay than for magnetic card swipe. But that report was not
correct, it misinterpreted who is getting the 10% discount, it's not the
merchant. See
<https://bankinnovation.net/2014/09/apple-said-to-negotiate-deep-payments-discounts-from-big-banks/>.

[Alan Browne]

On 2018-07-15 11:28, sms wrote:

> On 7/15/2018 7:53 AM, JF Mezei wrote:
>> On 2018-07-14 11:05, Alan Browne wrote:
>>
>>> about 86% Android to 13% iOS (worldwide).  So Apple's "influence" would
>>> be much larger if they deployed Apple Pay to Android.
>>
>> To a merchant, whether a customer uses any phone or any card makes no
>> difference. Bring thing near POS, POS terminal goes "beep" and
>> transction done.
>
> Actually there's a big difference. To smaller businesses the
> transactions are faster. That's a positive difference because it can
> reduce labor costs slightly.

There is 0 difference in speed between tap-to-pay and Apple Pay.

Examples: Where I buy gas it is 0 time. The phone or card is not even
"at" the terminal (pump) and it beeps done. About 15 cm away.

Where I buy some groceries and beer, it takes 0 .. 4 seconds whether I
use tap to pay or the phone.

What takes longer is chip readers. Several seconds to talk to the card,
then the user has to enter a PIN. (Users fumble on occasion with this).

[sms]

On 7/15/2018 6:30 AM, Alan Browne wrote:

<snip>

> And I keep replying that as far as the merchant and customer are
> concerned, fraud is not their liability where chip or Tap-to-pay is
> concerned.  You seem immune to these facts.

You're concerned only with liability for fraud.

It's not a question of who pays for fraud, the customer, the merchant,
or the card issuer, it's a question of how much fraud is committed since
eventually we all pay for it since it's factored into credit card fees.

In the U.S., where Chip & PIN is virtually non-existent, Google Pay and
Apple Pay are much more secure than Chip and Signature. In the civilized
world, where Chip & PIN is the norm, there's no significant advantage or
disadvantage, in terms of fraud, to Google Pay and Apple Pay.

One reason Costco could get such low fees from Citibank (on Costco
purchases) is that credit card fraud is extremely low at Costco. You
have to be a current member and your picture is on the card.

[nospam]

In article <piffi7$4q4$1...@dont-email.me>, sms
<scharf...@geemail.com> wrote:

>
> >> the suggestion for apple to bring it to android is beyond absurd.
> >
> > Indeed. People who make suggestions like that are just showing their
> > relative ignorance regarding security and hardware and software design.
> > I guess it's to be somewhat expected to some extent with technology
> > being put in the hands of the average Joe, but once it turns into a
> > debate with those who know better, it's a complete farce.
>
> No one is suggesting to bring any kind of mobile payment to non-secure
> phones.

except you, with your ludicrous suggestion of apple pay on android.

> But remember, the highest-rated phone for security is actually an
> Android model (the iPhone X is 2nd), but below 2nd place there are many
> highly-secure and sufficiently secure Android models.

bullshit. it's *very* easy to compromise android devices in all sorts
of ways.

now that iphones have usb restricted mode, it's basically impossible to
compromise any iphone made in the last 5 or so years (5s or later).

> You don't understand what is involved in developing secure applications
> for different platforms.

that would be you.

[nospam]

In article <piffl2$4q4$2...@dont-email.me>, sms

<scharf...@geemail.com> wrote:

> >>> 1) No because it does not have the requisite Apple Pay hardware required
> >>> by Apple Pay's spec.  eg: the Secure Enclave as implemented by Apple.
> >>> More important is how Apple Pay is implemented as an interface to the
> >>> banks - and that will be different than, Google Pay.
> >

> >> Android has had "Secure Enclave" since Marshmallow.
> >

> > Not really, since a secure enclave is not a software feature, it's
> > hardware.
>
> Actually it's both hardware and firmware.

nope. a secure enclave is hardware. period.

android phones that lack a secure enclave use hce, host card emulation,
which greatly simplified, can be thought of as a software version of a
secure enclave.

> Not every model has had the
> hardware of course, only higher-end models.

that part is true.

[nospam]

In article <9sSdnUzdgJD-0dbG...@giganews.com>, Alan Browne

<bitb...@blackhole.com> wrote:

> >>>> What made Apple Pay look so great to Americans was the lingering hang
> >>>> on of magnetic stripe cards in the US that was all but dead in the
> >>>> ROTW long before Apple Pay.
> >>>

> >>> Nope. It's still faster, more convenient, and more secure than chipped
> >>> cards, which the majority of Americans use today. You don't get to tell
> >>> Americans what we fucking like about Apple Pay. You can deny it all you
> >>
> >> Whiner. Fact is we had chipped cards AND tap to pay LONG before the US.
> >>
> >> So any advantage of Apple Pay presented as thin, watery stuff.
> >
> > nope.
> >
> > apple pay is faster and significantly more secure than chip cards.
>

> You keep saying that.

because it's true.

> And I keep replying: We've had tap-to-pay for a
> long time here, long before Apple Pay and it is just as fast (or as
> slow) as Apple Pay depending on the merchant terminal.

nope. apple pay is faster, regardless of merchant terminal speed, which
is a separate issue entirely.

double-squeeze watch, hold wrist. done.

no fumbling for wallet, finding the desired card, removing it and
tapping, inserting it back into wallet and putting wallet back into
pants

not all wallets are thin enough to tap without removing the card and if
you have more than one contactless card, there can be issues.

even faster in-app. tap pay with apple pay, authenticate fingerprint or
face, done. no need to type in card number, name, address, etc.

> eg: Where I usually get gas, tap-to-pay (or Apple Pay) is lightning
> fast. Where I usually buy beer, it's variable (quick to 3 or 4 seconds).

in the usa, you can do that at the same place in one purchase. :)

> And I keep replying that as far as the merchant and customer are
> concerned, fraud is not their liability where chip or Tap-to-pay is
> concerned. You seem immune to these facts.

you seem immune that *someone* pays for fraud.

the banks just pass it on to the merchants with higher interchange fees
and/or reduced awards for consumers and/or higher interest rates for
the cards.

one reason why banks were eager to pay apple a small fee is because
that amount was *less* than what they would have lost to fraud.

> So stop screaming about chip. Rarely use it 'cause I don't have to.

i'm not screaming about anything.

[nospam]

In article <WuydnaRsX6jX0NbG...@giganews.com>, Alan Browne

<bitb...@blackhole.com> wrote:

> >>>> What made Apple Pay look so great to Americans was the lingering hang on
> >>>> of magnetic stripe cards in the US that was all but dead in the ROTW

> >>>> long before Apple Pay. (We've had chipped cards for a long time before

> >>>> Tap To Pay).
> >>>
> >>> no, what makes apple pay great (and not just for looks) is that it's
> >>> effectively impossible to hack and that it does not provide any user
> >>> identifiable information to the merchant, not even a name, which makes
> >>> data mining linked back to the user impossible.
> >>
> >> Neither does tap-to-pay other than the CC number. The 3 digit security
> >> code is not transmitted. Nor the user's name. Nothing the merchant can
> >> use. And the merchant, transaction to transaction from the same card
> >> sees different numbers every time...
> >

> > once again, a stolen card can be used by *anyone*, tap, dip or swipe.
>

> And again (as you reply above the whole reply): No liability for customer.

so what?

the issue is security, not who is liable.

> And while a stolen iPhone won't work (1 in 10,000 chance it will) for
> tap to pay,

statistically, it's 1 out of 50k for a fingerprint to match, but that's
out of the general population.

the chances of the person who stole a phone being a match for the
original owner is *much* higher than that.

> an iPhone forgotten at home or completely discharged does
> not work at all.

a card forgotten at home does not work at all either.

[nospam]

In article <64ydnV8uDsdl0tbG...@giganews.com>, Alan Browne
<bitb...@blackhole.com> wrote:

> I never said chip transactions are quicker - and the real slow down is
> not the technical speed but the finger speed of the old lady in line who
> can't get her pin right...

never get in line behind old people.

[nospam]

In article <WuydnadsX6jk0NbG...@giganews.com>, Alan Browne

<bitb...@blackhole.com> wrote:

> >> One article stated that the percentage fee was slightly less for Apple
> >> Pay transactions versus swiped credit card transactions (up to 10%
> >> less), i.e. instead of 1.6% + 10¢ per transaction it would be 1.44% +
> >> 10¢ per transaction. Not sure if this is still the case.
> >>
> >> Assuming a 10% discount on fees, a business that did say $100K of credit
> >> card tranactions (5000 $20 transactions) a month would pay $1940 in
> >> monthly fees rather than $2100, a savings of $160 per month. Each $20
> >> transaction would cost 3.2¢ less, each $30 transaction would cost 4.8¢
> >> less. Not a huge savings, but better than nothing. Since presumably
> >> almost no business would be patronized based on whether or not they took
> >> Apple Pay, there has to be an upside to the business to accept it. A
> >> small savings in transaction costs, plus faster transactions, are two
> >> upsides.
> >
> > merchants do not pay any fees for apple pay.
>
> Want to bet on that?

yes.

<https://developer.apple.com/apple-pay/get-started/>
Are there additional fees to accept Apple Pay?

Apple does not charge users, merchants or developers to use Apple Pay
for payments.

you lose. pay up.