[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tarsnap died



OK, I have fixed all my email issues. I now have operative SPF, DKIM, & DMARC. And the big ISPs seem to be happy with it. I am getting regular DMARC reports from
yahoo and gmail & all is well.

I started up a new Tarsnap account. My existing tarsnap installation seems unable to talk to it though. Do I need to reinstall Tarsnap, create a new key etc?

              - Jerryk



On 2024-03-08 08:50, Norman Gray wrote:
Greetings

[trimming the CCs...]

This thread popped back into my head today, when I received a regular
reminder from another service I use, that it was about to renew.  The
alignment of emails prompts me to offer the observations below as
points of information, rather than necessarily advocating for anything
in particular

Short version: payment processing companies exist, and seem to do a
respectable job, in various senses.

I'm another person who thinks tarsnap's payment model is cute (and
long may it continue), but who would be more comfortable with a more
conventional one, as an option.

An email just appeared in my inbox saying

Your subscription will renew soon This is a friendly reminder that your XXX subscription for XXX will automatically renew on March 15, 2024. Your payment method on file will be charged at that time. If your billing information has changed, you can update your payment details (https://XXX) now. Or if you would like to cancel, please visit our
website. Questions? Contact us at XXX@XXX.

Powered by stripe logo (https://stripe.com)  |   Learn more about Stripe Billing (https://stripe.com/billing)

That ticks a lot of boxes for me.  It reminds me that Subscription X
is ongoing, it reassures me that I've got nothing to do, and it's
clear what to do if I decide to discontinue the service.  Good work,
Subscription X -- keep it up!

If I click on the 'learn more about Stripe Billing' link, I can find
more about compliance stuff, which includes documentation addressed to
the service owner [1] saying 'Checkout and Stripe.js and Elements host
all card data collection inputs within an iframe served from Stripe’s
domain (not yours) so your customers’ card information never touches
your servers.'  And lots more, more than I have the patience to read.
That is, the nice people at Subscription X (probably) _don't_ have my
card details stored locally.  However I'm fairly confident that
Subscription X (which includes being somewhat privacy-focused amongst
its declared goals) really _has_ read all that documentation.

Personally, I find this _more_ reassuring than if Subscription X were
managing this stuff themselves.  And more reassuring than if they were
doing something Imaginative and Creative about billing.
'Imaginative', 'creative' and 'billing' are not words that go well
together in a sentence!

Of course, there's the matter of trust.

I don't trust Stripe to be nice people, in a 'would I lend them money'
sense.  I've no reason to believe they're not sunlight-and-kittens
(though... financial organisation... the priors aren't good), but that
trust isn't part of the transaction.  I do, however, trust them to
look after my card details reasonably well, because doing so is the
entire point of their business, and if they were to visibly screw up
here, it could be devastating for them.  That's a very concrete
incentive.

There's more I could say here, but: for billing I want boring.

Best wishes,

Norman


[1] https://docs.stripe.com/security/guide#validating-pci-compliance