redact full shipping address from event until payment response

[marcoscaceres]

Redact:

• name
• phone
• address line(s)
• part of the zip. (+4 in US) ... um, we need to work that out.

[ianbjacobs]

@marcoscaceres,

Confirming I heard support for this during TPAC.
Ian

[jenan-stripe]

It's worth noting that a number of folks we've talked to have found partial postal code redaction insufficient for computation of shipping costs. +1 for standardizing on redaction of information that is inessential for calculations though.

[adrianba]

This sounds like it's going to get complicated fast. Are we really going to specify how to redact postal code information on a per country basis?

[marcoscaceres]

I think this will be a “the user agent MAY redact... for privacy reasons” situation. I don’t think we can be overly prescriptive.

[michelle]

Would it be worth including that fields critical to calculating shipping costs should not be redacted? If these fields are redacted, it makes the shippingaddresschange hook pretty useless. Of course, this means we'd need to specify which address fields are critical, and that might be an ever-changing set of fields.

[lyverovski]

Agree with @michelle. Redaction of the zip/postal makes it impossible to accurately calculate shipping costs. As @jenan-stripe mentions, partial postal code redaction is still insufficient.

For example in Canada, Postal Codes are formatted as A9A 9A9.
In the UK, Postal Codes are formatted one of 5 ways (AA9A 9AA, A9A 9AA, A9 9AA, AA9 9AA, AA99 9AA). Receiving only the first "group" of characters is insufficient to accurately calculate shipping address.

[marcoscaceres]

Would it be worth including that fields critical to calculating shipping costs should not be redacted? If these fields are redacted, it makes the shippingaddresschange hook pretty useless. Of course, this means we'd need to specify which address fields are critical, and that might be an ever-changing set of fields.

This would probably become problematic, because the merchants could just request "all the things" even when they don't need them. Thus, it would put us back in the situation we are in today.

Agree with @michelle. Redaction of the zip/postal makes it impossible to accurately calculate shipping costs. As @jenan-stripe mentions, partial postal code redaction is still insufficient.

Understood - but this is in contrast to what Apple Pay does, right? The spec can mandate that all fields get returned, but the user agent can still choose not to do that. It's better that the spec reflect reality. We have similar concerns in Mozilla around user privacy... so, it's just a matter of finding the right balance.

To be clear: no one is suggesting specifically saying that we should redact the post code. Just that we get a clear understanding of exactly what is universally critical to calculate the shipping. So, let's do exactly that.

Here is the list of attributes from PaymentAddress - let's work out which are critical (e.g., country), and which are definitely no no (e.g., recipient and phone), or might make no difference (e.g., organization?).

@michelle, @lyverovski, @jenan-stripe, as folks who know most in this area, can you categorize them and give a justification for why they are critical:

• country
• addressLine
• region
• city
• dependentLocality
• postalCode
• sortingCode
• languageCode
• organization
• recipient
• phone

[marcoscaceres]

Inversely, we can categorize them as "We can do without x, y, and z" to calculate shipping.

[michelle]

This would probably become problematic, because the merchants could just request "all the things" even when they don't need them. Thus, it would put us back in the situation we are in today.

Sorry, to be clear, I meant "we" as in, "folks working on the spec," not "the merchants." As you mentioned, I think we're all on the same page now: we need to come up with the critical fields for shipping :).

A rough, US-centric pass...

Critical, based on USPS / UPS / FedEx postage price tools:

• country
• postalCode
• city (UPS / FedEx only)
• region ?

Most likely unnecessary:

• sortingCode
• languageCode
• organization
• recipient
• phone

Ref:

• https://www.fedex.com/ratefinder/home?link=4&cc=US&language=en
• https://postcalc.usps.com/
• https://wwwapps.ups.com/calTimeCost?loc=emus%20
• https://www.ontrac.com/quickrates.asp

[marcoscaceres]

Ah, that's great @michelle! Adding another data point.

For Australia Post:

National:

• Country, city (suburb) can be ambiguous (e.g., "Springfield"), so post code is needed.

International:

• From post code/city (suburb)
• To: country
• To: post code (optional)

[jenan-stripe]

Probably need region as well, for countries with no postal codes? (Unverified!)

[marcoscaceres]

updated #648 (comment) to include region.

[adrianba]

What is the goal here though? If the goal is to be more privacy sensitive but you're not redacting part of the post code then you didn't really make much of a change. When I lived in the UK, my post code was unique to me and 4 neighbours. The only variable was the house number between 1 and 5.

[marcoscaceres]

What is the goal here though? If the goal is to be more privacy sensitive but you're not redacting part of the post code then you didn't really make much of a change. When I lived in the UK, my post code was unique to me and 4 neighbours. The only variable was the house number between 1 and 5.

Right now, the idea is to not pass along:

• recipient
• phone
• organization
• Possibly the addressLine.

for onshippingaddresschange. The above four literally identify you specifically. In my (Australian) case, my post code corresponds to 13,203 people spanning an area of 5.5km² (2.1 sq mi). That offers me some anonymity if I'm trying to check shipping costs or overall price but don't want to go through with the purchase.

Huge sorry to @zkoch and @rsolomakhin, but I'm going to use Chrome as an example. Here is what Chrome leaks right now onshippingaddresschange:

I've also checked, and Edge also leaks the above information to the site (sorry Edge folks 🙏).

So goal is to prevent the kind of leakage seen above. Yes, post-code may identify you as 1 in 5 people in the UK, but that's better than 1 in 1. And for much of the world, it does provide a bit of additional protection.

And yes, when the user hits pay, they reveal the full shipping details, including who it's being shipped to, etc., but that's to be expected by the user. That the browser is passing along all the details every time you pick a new address will likely surprise users - and it's fairly ripe for abuse.

[marcoscaceres]

I've got a PR ready to address this, but I'm still unsure about passing addressLine. From the websites we looked at above, addressLine is never needed... but addressLine does let you determine if the user is trying to ship to PO box, for instance.

Do we want to detect that early ("onshippingaddresschange")? or when we get the payment response?

(/me leaning towards including addressLine... anyone know what Apple does? @aestes, if you are watching?)

[adrianhopebailie]

@marcoscaceres I assume starting with less data and adding addressLine if there is demand is safer?

[aestes]

@marcoscaceres Apple Pay redacts addressLine

[marcoscaceres]

The problem is still trying to figure out how we can check for PO boxes, which, if we adopt this proposal, we couldn't do via PaymentRequest... which throws us into .retry() discussion (#647).

[marcoscaceres]

@aestes, given the redaction that ApplePay does, how do you currently deal with "we don't ship to PO boxes"?

[aestes]

You'd need to wait for onpaymentauthorized then do something like this:

session.onpaymentauthorized = (event) => {
    if (isPOBox(event.payment.shippingContact))
        session.completePayment(STATUS_FAILURE, [ new ApplePayError('shippingContactInvalid', 'addressLines', 'Cannot ship to P.O. boxes') ]);
};

The user would be prompted to correct the shipping address and retry the payment.

[ianbjacobs]

I'll mention in passing here that if we end up saying "Payment Request can be used to address this scenario and here's one way to do it..." then please let's add the example to our code example wiki:
https://github.com/w3c/payment-request-info/wiki/CodeExamples

Ian

[marcoscaceres]

@aestes, ok cool. So, you can only check for PO boxes after response is returned, but not during the request portion of the interaction. That's ok with me... let's see if we can then figure out retry() in #647.