There is a new law that allows merchants to stop giving paper receipts.

The forced use of e-receipts in Europe (France, Belgium, Netherlands, Denmark, England, & Italy)

That bug tracker is in MS Github - a place I will not go. And I have yet to find an organised or simple way to find downstream trackers. I generally check Debian but when a pkg is not in official Debian then I report to [email protected] and [email protected].

thanks!

I cannot see the image because it’s posted in the walled garden of #Cloudflare, which excludes me. Would someone please repost the image on an open-access instance or website so everyone can view it?

Gmail doesn’t care what the FROM field address is. It can be entirely unrelated to the sending server and can be complete gibberish nonsense. MS did not care either back when MS did not consider dynamic IPs blacklisted. Now that MS wholly rejects dynamic IPs I’m not interested in retesting that anyway.

Even from a narrow purely infosec-privacy PoV, how can people be so clueless this day in age with the fully enshitified web?

It’s not going to be a simple text email with your receipt attached. The email will be HTML with a tracker pixel (text MIME part broken or generally non-existent), so the seller can log the fact that you read the receipt, when, and with what IP address. Then when you get the email open, it won’t even contain the receipt because it will be used as an opportunity to get you on their website where they can get more sales. It will say “come to our website and pick up your receipt”. When you try to visit the site with the unique URL they send, Tor will be blocked (under the guise of “security” but in reality they want your browser print and IP again in case you used a text-only MUA). This will give them what makes it trivial to link your online identity to your offline purchase (cha-ching… mo money). Then a Google Plastore-only non-FOSS app will be shoved in your face as a more convenient way to fetch your receipts in the future. You will have to solve a CAPTCHA to reach your receipt, which generates more profit for them while steering people toward a shitty app.

It will be like London Heathrow or JFK airport, where you cannot simply walk to your gate without being long-hauled through a series of marketing opportunities.

And before you irrationally call this “paranoia” as well, I will preempt that by saying no, it’s capitalism. Which brings us the enshitified web.

NFC would encourage phone upgrading which is worse for the environment than the problem they think they are solving. Paper is biodegradable. Phones are not.

Android 2.3+¹ supports bluetooth file transfers. This would avoid both the problem of using cloud energy and privacy problem (but only for smartphone owners who carry their smartphones). The article mentioned PDF being rejected. PNG could work, though it’d be a missed opportunity to get a digitally signed receipt. In any case, the paper receipt cannot be wholly replaced if it requires consumers to have a phone and to carry it, or if it requires sharing email addresses.

¹ maybe even AOS 1.8… didn’t check

Privacy is about control.

You don’t understand privacy given your conflation with paranoia and oversight of my mention of a boycott. Privacy is not just about non-disclosure of sensitive information. It’s much more than infosec.

When you mislabel privacy as “paranoia”, you become part of the problem of advocating disempowerment of people in favor of control misappropriation.

If you don’t want to receive emails from servers belonging to Microsoft, Google, or Amazon, you better delete your mail account and ask them to mail you the receipt.

This absurd attempt at a false dichotomy showcases contempt for individuals having power to boycott selectively. What you suggest is wholly disempowering to people – to claim this all or nothing narrative… that people should either not have email access at all, or they should have zero control over who they connect with over email. Your stance represents a boot-licking wet dream for corporations and governments. It has no place in any privacy community.

I’m fine with all that. I’ve mostly abandoned #email anyway because I do not accept the terms Google has imposed on the world. I send most messages by postal mail when recipients have only exclusive and restrictive receiving options.

The inability of the recipient to reply to an onion address using their normal service is actually part of the idea. I would not want a gmail user to be able to use gmail to reply, for example. While Google drags people into their walled garden, I’m happy to exert pressure in the opposite direction.

(edit)
If I were to send a msg to gmail user in a way that they could simply reply from Google, then I become part of the problem by reinforcing the use of Gmail and helping Google get fed. That’s not going to happen. It’s a non-starter.

That is 100% what im saying, yes.

Okay, so AFAICT you’ve not said anything that prevents individual users from using an onion FROM address, so long as the sending server is authorized via all the shitty spf, dkim, dmarc, dane hoops. This is what I’m after. In fact, I’m even less demanding. I don’t care if a service provider doesn’t bother with dkim and gets rejected by some servers. Email is in such a broken state anyway… I just need the option to set the FROM field to an onion address. The reason my own server is insufficient is the residential IP is very widely rejected.

I’m not surprised. Google took an anti-RFC posture when they broke email and brought in their own rules under the guise of anti-spam (the real reason is domination). The whole point of RFCs existence is interoperability. That was broken when servers reject RFC-compliant messages.

I’m not interested in bending over backwards to accommodate. Satisfying Google’s dkim reqs requires the server admin to solve a CAPTCHA. That’s a line I personally will not cross. So at the moment I simply do not email gmail users (or MS Outlook users, same problem).

The server is checking that the EHLO domain matches that of the IP of the sending server. Whatever is in the FROM: field is entirely irrelevant to that. The RFC even allows multiple email addresses in the FROM field. It’s rarely practiced, but it’s compliant. So if you have FROM: [email protected], [email protected], [email protected], are you saying the receiving server would expect the domain of all FROM addresses to match that of the sending server? What happens when a sender has a gmail account but uses a vanity address? Instead of [email protected], he has [email protected]. Are you saying expertcorp.com ≠ gmail.com, so the receiving server will reject it? I think not. Google offers the ability of their users to use an external address last time I checked.

If you monitor IRC channels on email servers, you’ll find there are plenty of email admins unwilling to even go through the dkim and dmarc hoops. An fqdn check not on the sending server but on the FROM field of a msg is over-zealously above and beyond dkim and dmarc. I’m quite fine with not reaching these fringe servers. I can always decide from the bounce msg whether it’s worth my effort to dignify their excessive hoops with a transmission to their persnickety liking.

How do you expect to receive replies from clearnet users, or are you okay not receiving replies?

Indeed that’s the idea. If you’ve ever received a message where the sender’s address is “[email protected]”, it’s similar. But in fact the onion address is slightly more useful than a “noreply” address because the responder would at least have the option of registering with an onion-capable email server to reply.

Imagine you want to email a gmail user. You can ensure that the message contains nothing you don’t mind sharing with a surveillance advertiser, but you cannot generally control what gets shared in the response. An onion address ensures that replies will be outside of Google’s walled garden, for example. That’s just one of several use cases.

Also most mail hosts these days toss emails that dont match dmarc/dkim/spf, which would be especially hard to do for an onion email

Those are server to server authentication protocols, not something that validates the functionality of a sender’s disclosed email address. Otherwise how would a bank send an announcement from a “noreply” address?

Do you know who does care? The email server you’re sending messages to, because spammers and scammers love to try and send email with fake from addresses.

The receiving servers do not generally care what’s in the FROM field. They care that the sending server they are connected to is authorized and has their SPF, DKIM, and DMARC shit together. It’s not for the receiving server to control the email aliases of individual senders. Some rare over-zealous servers will look at the FROM field and expect the domain to match but if I encounter that, the collateral damage is what it is. I can always still decide from there whether it’s worthwhile to go through extra hoops.

People are pushovers and tend not to give a shit about banks excessively following the know-your-customer protocol well beyond what the law even requires. So why not mirror that success in the telecom domain? Followed by grocery stores and car mechanics next…

Are you wanting to have a .onion TLD email address,

Yes, and that much exists. There are onion email providers, but when you email a clearnet recipient, they typically convert your onion email address to a clearnet address. That’s useful in most situations but there are also several use cases for not doing the conversion. But finding a service that accommodates the other use cases is hard, considering onion email is rare in itself.

and be able to communicate with non-TOR web servers?

No, nothing to do with the web. Just email.

The host needs to be able to look up addresses, and resolve them to a location.

Only for replies. But not all messages need a reply. See my other msg.

It would require having clearnet servers also connected to the TOR network which I would imagine is incredibly unlikely.

Those exist already (danwin, riseup, onionmail, etc). But they operate on the assumption that senders always want replies from the recipient to be possible via their receiving server. That’s not always desirable.

In the same way you can browse non onion sites through TOR but not the other way around,

There is a service that enables clearnet users to reach onion services (onion.to, onion.cat, etc), but this is unrelated. Web is unrelated.

you would likely be able to send email but not receive them

Bingo. That’s the point in some of the use cases.

Delete hosted cloud. Move back to hosting your own.

How does that address the problem or promote privacy? Self-hosting makes it even more trivially easy to identify you. E.g. if I run my own Lemmy server, it would transact on an IP address that points to me. By anonymously creating an acct sopuli.xyz and using Tor, doxxing becomes harder.

Not really an option

Sure it is. I can theoretically¹ do it myself with my mail server. If you use a mail client like (neo)mutt, you can literally free type whatever you want to put in the FROM field. IIRC, this contradicts no RFCs so long as there is a syntactically valid email address.

Ever get an email with a bogus address like “[email protected]”? It’s essentially the same. Not all e-mail addresses in the FROM field go to valid inboxes – nor are they required to.

since the onion TLD isn’t accessible to clearnet servers. How are email servers supposed to reach out the onion domain name and mail server if they can’t resolve it?

You’re talking about using the FROM address for replying purposes. The point of having this option is to make replies very difficult, but still possible.

Mail servers can be configured to handle onion addresses. I’ve configured postfix to do that. But indeed most servers are not configured to handle onions, which any users who make use of the feature would need to be aware of. It’s a useful scenario because it can be used to force recipients out of Google’s and Microsoft’s walled gardens, and give them incentive to join the free world away from surveillance advertisers, for example. They must join an onion-capable email service if they want to reply.

StreetComplete shows me no map, just quests on a blank canvas. OSMand shows my offline maps just fine, but apparently StreetComplete has no way to reach the offline maps. I suppose that’s down to Android security – each app has it’s own storage space secure from other apps.

In principle, we should be able to put the maps on shared SD card space and both apps should access it. But StreetComplete gives no way in the settings of specifying the map location. And apparently it fails to fetch an extra copy of the maps as well in my case.