No longer require apps to use HTTPS for in-app payments

RESOLVED FIXED in 2013-08-13

Status

Marketplace
Payments/Refunds
P3
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: kumar, Assigned: kumar)

Tracking

2013-08-13
Points:
---

Details

(Whiteboard: [qa-])

To make a developer's life easier, no longer require HTTPS for in-app payments. See this thread for rationale: https://groups.google.com/d/msg/mozilla.dev.webapps/4cSWLJ-3Ahs/L5C5gjFUqikJ

Summary:
- SSL certs can be bought cheaply in the US/Europe
- However, certs might be prohibitively expensive in some economies (like emerging markets)
- SSL is *not* required to make in-app payments secure
- SSL will probably make replay attacks harder if the app is susceptible to such

As part of this feature, let's add these things to the docs:
- a big red warning urging developers to use HTTPS if possible
- an explanation of replay attacks and how to protect an app against replays
Blocks: 775802
Priority: -- → P3
Blocks: 846517
No longer blocks: 775802
OS: Mac OS X → All
Hardware: x86 → All
Okay, I'm confused. Is the work in this bug client-side in the mozPay level, gaia system level, and/or marketplace level?
It's entirely at the marketplace level; it does not impact the client in any way. Is it ok to block bug 775802 for our tracking purposes?
(In reply to Kumar McMillan [:kumar] from comment #2)
> It's entirely at the marketplace level; it does not impact the client in any
> way. Is it ok to block bug 775802 for our tracking purposes?

Yes, that makes sense.
Blocks: 775802
No longer blocks: 846517
Assignee: nobody → kumar.mcmillan
I think it is important to note in the implementation of this that no PII is allowed to be sent over a non-HTTPS connection, which means that in general the marketplace <-> app developer server communication cannot contain PII.
what is PII?
(In reply to Kumar McMillan [:kumar] from comment #5)
> what is PII?

Personally identifiable information: people's names, email addresses, social security numbers, addresses, phone numbers, other unique identifiers mapped to a person.
Ah, good point. Mozilla would never send this information but a developer might transmit this information unknowningly in the productData JWT field. I'll add a warning in the docs to urge developers not to send PII.
Target Milestone: --- → 2013-07-25
Target Milestone: 2013-07-25 → 2013-08-01
Target Milestone: 2013-08-01 → 2013-08-08
Target Milestone: 2013-08-06 → 2013-08-13
This fix has landed: https://github.com/mozilla/webpay/commit/638d50138cc42d951f615c83a146bce103c8c8bb

The documentation has a scary callout about the risks of using HTTP postbacks: https://developer.mozilla.org/en-US/docs/Web/Apps/Publishing/In-app_payments#Use_HTTPS_postback.2Fchargeback_URLs
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 9

4 years ago
Please add STR here or mark it with [qa-] if no QA is needed.
Flags: needinfo?
STR would be:
- set up an app to do in-app payments per https://developer.mozilla.org/en-US/docs/Web/Apps/Publishing/In-app_payments
- configure the app with an HTTP postback
- make a non-simulated payment which means setting up a fake bank account in dev/stage

These steps are non-trivial so if you want to make it as [qa-] then I'll leave it up to you.

Here's an example app that you could work from: https://github.com/kumar303/inapp-pay-test
Flags: needinfo?

Comment 11

4 years ago
I'm not sure how to make a non-simulated payment using the app you provided. I'll mark it as [qa-]
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.