logoalt Hacker News

fluidcrufttoday at 12:16 PM7 repliesview on HN

Generally I think the issue is that there's a tension between your security vs Paypal's security (deliberate, motivated bad actors).

Maybe an analogy could be about using metal detectors as a layer to reduce bank robberies. A gun in a good guy's hands is a good thing to prevent robberies. Guns in a bad guy's hands are a bad thing to prevent robberies. Paypal knows you have a gun but they don't know if you're a good guy or a bad guy so it's easier to just ban guns.


Replies

axegon_today at 12:41 PM

That's your argument? Mate, you can make explosives out of stuff you can buy in literally any supermarket and no one bats an eyelash. You don't have to legally be adult to buy any of the things you'd need and I say that as someone who only struggled with chemistry in school, that's now low the bar is. What's the solution then? Ban sea salt? If someone is using Graphene, the chances of them getting hacked are astronomically lower than any Chinese spyware-infested phone.

show 2 replies
RunSettoday at 2:26 PM

> Maybe an analogy could be about using metal detectors as a layer to reduce bank robberies.

A more apt analogy might be game developers who demand admin rights so they can install a rootkit to detect "cheating".

brightballtoday at 1:05 PM

Yea, years ago I was in the security space and got to talk to some paypal security folks at a symposium in San Diego. The level of stuff that they have to deal with is so extreme.

It's similar to how people don't like sites blocking entire countries or access from Tor, etc. You might be doing it for privacy...but all the people trying to commit fraud are also using those same channels to hide their identity. The blockades are one piece of a holistic security picture that frustrate the well intentioned users.

show 1 reply
kevin_thibedeautoday at 2:02 PM

The cherry on top is that their web site invariably still works so the refusal to work via app is an intentional manipulation tactic to harvest more consumer data for sale.

show 1 reply
dmichulketoday at 1:21 PM

To stay with your analogy, there is no technical obstacle to treating the customer of 15 years differently to the newly onboarded one.

They have all the data they need, and they choose not to use it.

show 1 reply
encomtoday at 12:17 PM

How does a rooted phone enable bank fraud? This smells like pointless policy checkboxing.

show 3 replies
dathinabtoday at 1:54 PM

this isn't quite true

From a Paypal security POV, weather you use "custom Android OS" or an hugely outdated Android phone, you have:

- a similar risk for the "you" want to mess with Paypal case, in both cases the "you" can technically most likely mess with anything including the "virtual secure module" thingy android uses for NFC

- a lower risk for "others" wanting to mess with Paypal through your phone, at least if "custom Android OS" is GrapheneOS or another up-to-date android fork with decent security handling

so as far as I can tell, this inconsistency is very clearly not about PayPal's security.

IMHO it's about two other things:

1. marketing, if PayPal doesn't work on Android they lose customers, GrapheneOS for now has a tool small customer base for them to care. Outdated Android phone do have a large customer base.

2. compliance/politics BS. including potentially involving insurance. Compliance is mostly about checking of tickmarks(1) on outdated Android they can check them off and blame the user, Goodle or "hackers" for the issue. On GraphemeOS they have a harder time checking it of. Add the smaller user base and end up with PayPal doesn't care. Also iff things go wrong with Paypal on GraphemeOS in a public manner you will have all the "crime os" bad news bs, you won't have that if things go wrong with a even more risky highly outdated Android phone.

-----------------------

I got a bit to much off topic below:

(^1): Technically compliance should be about building robust, secure, law compliant systems and "showing" that by being able to pass a compliance tests consisting about a bunch of requirements. Practically there is way to many ways you can be "fully compliant" (on paper) but not secure and "very secure" but not compliant (wrt. security regulations). In the former case this might still come back and bite you iff you get sued or people suing which should get right don't get it because of ad-absurbum reasoning like "they comply with security regulations, hence can't have acted negligent". It's a shit show I don't know how to fix even if I could just magically change laws as compliance rules need technological flexibility, but if you give them that that will be abused to make insecure things pass. And the whole industry around checking that isn't really one who cares about actual security, sometimes outright corrupt (like groups which have the necessary accredited to check your compliance, are strangely more expensive then other groups, and somehow find less issues in average, with some excuse of why that isn't strange ...) :/

---

Lastly similar to how Teams or Slack could easily support FF (^2) but not only don't but outright refuse to try to even work. PayPal likes to act similar and doesn't care about niches. E.g. at least on some Mobile browsers WebAuthn works, but the PayPal website refuses to _even try_ 2FA with WebAuthn on mobile no matter if the APIs are there or not.

(^2): Yes there are some challenges, AFIK especially in certain edge cases most user might never run into. But Jitsi made it work, other smaller apps also made it work. And Jitsi is open source, so they technically can "look up" all the tricks to make it work (algorithmic ticks, not copy-pasting code) or outright just use their system with an appropriate contract (probably would be even cheaper wrt. maintenance cost then building your own system). At Slack/MS Teams scale that behavior is just messed up.