No. It’s either the responsibility of the OS provider, or the maker of the software you are using to access the site or resource. Websites do not have the ability to install trusted certificates on your computer. That would be a major security flaw.

>Otherwise, it's being reported as income to the IRS, and most of you are doxxed.

Send me lots of free money unasked, then threaten to let me keep it and report it as income? Ok, sure, I'll pay the 30% tax on whatever it is to be able to keep the other 70%. No problem. :handshake:

I've worked for an ESP for the last decade (actually several, but it's complicated to describe). I've been going to M3AAWG conferences twice a year for the last 12 years. At those conferences I have meetings, see presentations by, and/or socialize over drinks with pretty much all the Postmasters of all the major receivers. Google gave M3AAWG plenty of head's up that the image proxy change was coming, why, and what it actually does; they're usually good about sharing general information like that with M3AAWG members because we're all committed to eliminating outright abuse from our platforms (e.g. clear spammers) and reducing inadvertent abuse (e.g. Joe from marketing brought his list over from his last company).

It's crazy how wrong this is.

> Immediately when an email is received, Google loads the images in it and stores a local copy for when the use wants to read the email

No, they don't.

> in fact, whether or not the Gmail account to which the mail is addressed even exists.

No, they don't, *especially* if the Gmail account doesn't exist. Like every other provider, if an account doesn't exist, they reject the message before any of the data has even been sent.

> Thus, anyone who sends a mail to a Gmail account can count on the tracking image being read - but by the server, not the user.

ergo, this isn't true at all.

The thing that Google _does_ do is to load all images in an email via an image proxy. That obfuscates the IP, user-agent, and other information about the recipient looking at the message. All images are loaded at time of opening though.

> Gmail or Live/Outlook anyway, which will happily scan your email and give way more metrics back than a tracking pixel will to begin with

They _absolutely_ do not share any data with email senders that is interesting, in the least. At the most broad they provide aggregate complaint rates per sending IP (GPT or SNDS). At the most specific, they will forward back to you the entire email that a user reported as spam as part of their FBL process (Gmail doesn't even do this).

The do not share any data about inbox placement, opens, clicks, shares, or any other activity related to an email you sent, period, with anyone. Full stop.

This is exactly how it operates, and also means that whoever works at Helm has access to your email in transit. I for one don't trust a startup to have vetted their employees well, nor to have the security measures in place to protect the systems from compromise.

OP seems a bit disingenuous. For every one, he followed up minutes later with a more fleshed out and responsive answer. It seems obviously to me that his original comments were markers to track which ones he wanted to come back to.

This is just the initial list. It sounds like all games are compatible and the only thing keeping them is a new agreement/addendum with the Publishers to distribute them there.

(*) actual speeds not guaranteed.

It's in every agreement so to them, they _are_ providing the service they claim.

I would beg to differ on this. For CI, you can easily use spot instances which are dirt cheap. We pay $0.07/hr for ours. Assuming we had a build running 24x7x365, that's $613.20 per year costs. You'd be hard pressed to find a decent box for that price. Additionally, builds are not happening 24x7x365, but rather only when changes are made so your costs are even better than hardware, which is sitting idle and using power and rack space during the interim.

We're using OnDemand for CI of everything and CD for some. We use spot instances for the workers because we don't mind waiting a bit for the test to happen. We typically have to wait ~3.5 minutes to get an instance but are only paying $0.07/hr for that instance. It's ridiculously cheap for us to do it this way.

Thank you. So, I can think of QAM in the same way as a PRI and Comcast would be setting aside one or more channels for Apple (or other) traffic.

There's no 'separate pathway' over a single line. Are they talking about QoS?

Good, it's public now. I don't have to RTFS because I was there when they announced and described this and had a chance to ask questions about it. It is brand new as of last Thursday and it is not an ARF based FBL. It is a single daily report that will give ESPs an idea of how their emails are being handled by the Google classifier. It will not be useful as an unsubscribe mechanism as it will not include any recipient specific data. Only ESPs are eligible and even then it will be limited as they roll it out and get feedback about the new service.

So, no, they still don't have an ARF based FBL.

Maybe legally but for most ISPs these days: spam is that which that their customers do not want to receive. I've heard it directly from postmasters at the majors. It doesn't matter if they opted in, have a relationship or any of that. If the customer no longer wants to receive it, it's spam. That's the base operating premise at this point.