[HN Gopher] AMP and why emails are not (and should never be) int...
___________________________________________________________________
AMP and why emails are not (and should never be) interactive
Author : maguay
Score : 169 points
Date : 2025-04-18 07:31 UTC (15 hours ago)
(HTM) web link (buttondown.com)
(TXT) w3m dump (buttondown.com)
| Spivak wrote:
| I'm gonna take the other end of the luddite argument-- this is
| cool as hell and they should lean into it more. Discord has
| proven that an app platform hiding underneath IRC is hugely
| popular. Email with the power of discord integrations and bots
| would get me to up drop gmail immediately.
| AlexandrB wrote:
| It _could_ be cool as hell if it would be used for any purpose
| other than sending marketing communication. But, unfortunately,
| we live in this world.
| bayindirh wrote:
| No, thank you. E-Mail is designed to be an analog to, well,
| analog mail. I expect to open the same e-mail 5 years later and
| see it intact, in meaning sense.
|
| For interactivity, we have web pages, and they seem to work
| fine.
|
| This doesn't compare with Discord, because Discord is meant to
| be a "chat" platform for ephemeral issues to begin with (yet
| it's abused as a permanent platform), and AMP for e-mail is
| abusing a platform designed for permanence for temporary
| communications.
|
| That's a bad idea(TM).
| goku12 wrote:
| The use case you described is genuine. But the problem I see
| here is the insistence that the email platform should fulfill
| those requirements instead of creating a new platform and
| letting it win the market on its own merit.
|
| People have certain expectations from emails, which have
| remained largely unchanged since the emergence of the internet.
| Those include a federated and fully open platform, immutability
| of messages that make it valuable as communication records,
| privacy afforded by plaintext, simplicity of use, etc. Many
| changes have already ruined some of those qualities of emails.
| For example, introduction of HTML in emails have converted
| emails from a messaging platform to an ad and tracking
| platform, forcing many clients to block dynamically loaded
| resources. Quoting of prior messages have become a complete
| mess. But worst of all, the email platform is arguably no
| longer fully federated, now that it's nearly impossible to self
| host email servers.
|
| It wouldn't be a stretch to argue that changes like these are
| intended more to centralize the email network than to add
| features to it. AMP is a clear aggression in that step. It's
| telling that neither AMP for web, nor AMP for email survived
| once Google was forced to stop pushing the so aggressively.
| Makes you question who wanted it so badly and why.
| surajrmal wrote:
| The chance of another distributed platform with the
| properties desired seems small. Why should email be resistant
| to any change? Takes like this is why every company develops
| their platforms as silos rather than open standards. To avoid
| the inability to ever make a change once it becomes popular.
| Instead, at best, we end up with large monocultures around an
| open source project such as Linux or chromium. Maybe that's
| better and email like platforms are a mistake, but
| fundamentally I don't feel like that should be true.
| trollbridge wrote:
| Such an "interactive" use would need to keep the basic
| structure of email; for example, a bot you can email and it
| talks back to you. (Such things have been tried before, but
| never really caught on.)
|
| If Discord had the same spam or mass marketing problems that
| email and postal mail have, nobody would willingly use Discord.
| As it stands, the primary purpose of email is to get
| authentication codes emailed to you so you can login to other
| things.
| Kwpolska wrote:
| Discord is not built on IRC. It's a completely custom,
| proprietary thing. "Servers" are not separate machines, as they
| are in IRC land, they're just groups of channels.
| tacker2000 wrote:
| Discord is the worst platform of all. All content is hidden for
| outsiders, non-indexable by search engines, its the prime
| example of non-open siloed knowledge. To this day I will not
| use a project if it heavily relies on discord. All of the
| content could be gone at once, at the whims of one company.
| room271 wrote:
| While I agree with this article's conclusion, I think it
| conflates political/market objections to AMP (i.e. abuse of
| monopoly power) with technical concerns.
|
| For a time, I tech-led the creation of the AMP site for a major
| news publisher. The technical choices of AMP, excluding the CDN-
| aspect, are I think a great fit for publishing websites with
| tens-hundreds of developers who are all tempted to write bespoke
| JS and in so doing create performance and maintenance hell. In
| many respects, philosophically, I think AMP was not far of HTMX.
| In AMP, developers are able to construct relatively sophisticated
| dynamic/interactive features using simple markup (and pre-built
| JS components). The page is managed through a single JS runtime
| which helps manage performance issues. As components have a
| standard HTML interface, it is possible to migrate the backend to
| different rendering technologies partially over time unlike (for
| example), isomorphic JS which forces a large-scale rewrite down
| the line.
|
| I tried to advocate for an in-house AMP-like solution for our
| main website, but it was ultimately re-written in React -- a
| process which took several years and resulted in a codebase of
| much greater complexity. (Performance was better than the old
| website but I'm not sure React really contributed to the gains
| here.)
|
| While AMP is rightly dead, I think the technical choices it made
| live on (or at least, they should).
| trollbridge wrote:
| AMP seemed like a great technology that ended up being used for
| user-hostile purposes.
| Henchman21 wrote:
| If you swap out AMP for ${generic_tech} this statement seems
| to describe the latest 15 years of software development.
| throwaway28692 wrote:
| It was never user-hostile. It was definitely publisher
| hostile but that isn't the same thing.
| MaxBarraclough wrote:
| Perhaps I'm just being dense, but I really don't see the point
| of AMP. If you want to build a non-bloated website, you don't
| need special branding from Google to do so, you just need to
| care about the quality of your work. Websites like HackerNews,
| SourceHut, and Pinboard, are living proof.
|
| The Wikipedia article does a very poor job, in my opinion, of
| explaining what AMP even is. [0] It emphasises use of CDN
| caching to improve performance, but this can be done for any
| static website. What does AMP contribute? Where's the
| innovation?
|
| [0] https://en.wikipedia.org/wiki/Accelerated_Mobile_Pages
| jeffbee wrote:
| AMP is a set of rules for people who are unable to stop
| themselves from making bad decisions. It has nothing to do
| with technical superiority. AMP is a deal under which, if an
| adopter stops acting like a jackass, they receive better
| search ranking. There is nothing that stops you from creating
| an AMP-like experience if you are naturally not a jackass.
| bayindirh wrote:
| > AMP is a deal under which, if an adopter stops acting
| like a jackass, they receive better search ranking.
|
| You mean, jackassery like, not running ads from Google's ad
| platform(s)?
| jeffbee wrote:
| AMP has no relationship to Google Ads, does not require
| Google Ads, and does not require using Google's CDN.
| There are dozens of ad networks that support(ed) AMP.
|
| Google Ads has integrations for AMP. AMP does not require
| Google Ads.
| jmholla wrote:
| Perhaps not directly, but from the article:
|
| > AMP required allowing any AMP CDN to cache your pages.
| Visitors might be served your page from a Google domain
| instead of your own, or the ad tech and other scripts on
| your site might be incapable of running on your AMP site
| (handily, it seemed, for Google, who might prefer you to
| use their ad tech instead).
| jeffbee wrote:
| Part of that statement is correct, part of it is
| misleading.
|
| > AMP required allowing any AMP CDN to cache your pages.
|
| Sort of correct: this is true if and only if you wanted
| the rank boost for Google search. If you just wanted to
| serve AMP and have snappy page, not entirely correct.
|
| > other scripts on your site might be incapable of
| running on your AMP site
|
| Correct, because that's the entire point of AMP. It is a
| straightjacket intended to make it technically impossible
| for your "other scripts" to run, because actual users
| hate your "other scripts" and they make users' phones
| overheat etc.
| dccoolgai wrote:
| Exactly this. AMP was not a technological concern so much
| as a "contract": I won't act like a jackass and do anti-
| user things on my site and you will convey that to your
| readers/searchers.
| kevin_thibedeau wrote:
| Doesn't seem to prevent AMP sites promoted on
| Android/Google/Gemini assistant from using dick moves like
| hijacking the back button to prevent you from leaving. I
| can't fathom why Google doesn't drop the hammer on that
| behavior.
| sanderjd wrote:
| It wasn't innovative or intended to be, it was a solution to
| a collective action problem. It's easy to make the case for
| "we have to do it this way to avoid being penalized in search
| rankings".
| MaxBarraclough wrote:
| Doesn't Google already penalise websites for poor
| performance though? Why not just intensify that penalty,
| rather than develop and promote a new framework intended to
| forcibly prohibit bloat?
| jeffbee wrote:
| Sure but people won't always respond to incentives. It's
| like asking why AA exists when the cops will already
| throw you in jail for being drunk in public.
|
| Google will rank results partially based on page
| performance and behavior. It is possible to improve your
| ranking by improving page experience. AMP is the
| complement: a tech stack that makes it impossible to not
| do those things.
| xp84 wrote:
| When nearly every site has horrible performance IDK if it
| would make a difference to intensify those penalties, as
| they'd apply about equally for instance to every news
| site, every blog, every e-commerce site, etc.
| ec109685 wrote:
| With AMP, Google could preload and pre-render sites, so
| things like swiping through a carousel between search results
| was instant.
|
| That's not possible without building an AMP page since it
| requires being able to safely serve off of google's domain.
| lern_too_spel wrote:
| The innovation is that the page can be _prerendered_ from
| cache without any privacy or analytics concerns. AMP is an
| open standard replacement for Facebook Instant Articles and
| Apple News Format.
|
| https://en.wikipedia.org/wiki/Facebook_Instant_Articles
|
| https://developer.apple.com/documentation/applenewsformat
| 3np wrote:
| Prerendering was old-school back then, too.
|
| Edge caching might not have been as prevalent but was
| hardly new technology.
|
| > without any privacy or analytics concerns
|
| Uhm, yeah, no. Less bloated JS usually means less concerns
| but privacy violations and tracking of visitors can very
| much happen on AMP. Some of that risk isn't removed, just
| shifted.
| ravenstine wrote:
| With AMP, you basically get guard-rails to prevent your team
| of junior engineers from making your mobile pages too slow in
| exchange for increasing The Google's monopoly power. :D If I
| remember correctly, with AMP, you _have_ to use their web
| components, and you _have_ to pass their validator or pages
| won 't be listed or cached at all. AMP is not really
| innovative in the slightest. One can easily serve pages
| faster than an average AMP page if they wanted to. The
| businesses that see engineering as a _necessary evil_ are not
| properly incentivized to care about page performance, and are
| sometimes only prodded into doing so if a giant like The
| Google tells them to. Management tells their programmers that
| they read an article about AMP and that it makes pages load
| faster and reaches a wider search audience by caching and
| cutting out unnecessary crap; the more seasoned programmers
| think "Yeah, no shit - I've been trying to tell you... but
| I'll spend time rebuilding pages for AMP because I get paid
| the same either way."
| lern_too_spel wrote:
| > One can easily serve pages faster than an average AMP
| page if they wanted to
|
| This is incorrect. You cannot beat prerendered. It does not
| make sense to implement AMP for people visiting your
| website directly. AMP is for link aggregators like search
| engines, news aggregators, and social media websites.
| throwaway28692 wrote:
| The point of AMP was to force publishers to build non-bloated
| websites, because they weren't doing it of their own free
| will.
| EvanAnderson wrote:
| > ...it conflates political/market objections to AMP (i.e.
| abuse of monopoly power)...
|
| It never occurred to me that AMP is an initialism for "Abuse of
| Monopoly Power". It's deliciously fitting.
| BiteCode_dev wrote:
| It's "accelerated mobile pages" but I love the abuse version.
| marcellus23 wrote:
| Well yes, obviously Google didn't _actually_ name it for
| Abuse of Monopoly Power.
| ceejayoz wrote:
| Not publicly, at least.
|
| They've put some seriously dumb admissions in writing
| before.
|
| https://www.techemails.com/p/sergey-brin-irate-call-from-
| ste...
| Lammy wrote:
| They learned from this and now just have periodic
| arbitrary layoffs to depress salaries and keep the
| workers scared and in line in a deniable way instead of
| in an explicit way.
| no_wizard wrote:
| I like AMP conceptually, would make a good app platform for
| alot of types of websites and such.
|
| I wish it was easier to fork, honestly. There's some good ideas
| within, though some questionable choices as well.
|
| Unfortunately the project is rather opaque in a number of ways
| lern_too_spel wrote:
| How would forking work? The whole point of AMP is that a
| cache can validate that it is safe to prerender. If you added
| your own stuff, the caches would just reject it.
| hn_throwaway_99 wrote:
| Yeah, while I basically loathed AMP for all the control and
| monopolization issues, I do see what Google was trying to
| accomplish, at least at first.
|
| Any front end dev has had to deal with the onslaught of asks
| from various marketing and sales teams: "Can you add this tag
| library?", "We need to integrate this affiliate broker!", etc.
| etc. And lots of devs would push back with stuff like "At this
| point we load 247 3rd party tags and JS libraries and it takes
| 53 seconds for our page to load, we have to stop this madness!"
| but the problem was that for any _individual_ marketing team
| ask, the impact was small and of course that team had some KPIs
| to hit this quarter. It was basically a sort of Tragedy of the
| Commons situation.
|
| So AMP came along and essentially gave front-end devs a
| _technical_ reason why they couldn 't add some shitty, slow,
| buggy affiliate broker JS library to the code base, so when
| marketing came with an ask, they could simply say "Sorry, not
| supported in AMP, and without AMP we get downranked in Google".
| AMP essentially became a technical hack to align short term
| incentives ("We need to add some marketing feature X!") with
| longer term goals of faster, lighter-weight pages.
| thehappypm wrote:
| Yep. I totally see why they did it. It's a user focus, not
| developer focus. Users just want faster webpages. The end.
| charcircuit wrote:
| >without AMP we get downranked in Google
|
| Whether a site used AMP did not affect ranking in Google.
| wombatpm wrote:
| Ranking is a closely held secret. Non AMP COULD have a
| negative impact. Let marketing try and get confirmation
| from Google that it does not.
| hn_throwaway_99 wrote:
| You're either uninformed or splitting hairs about what
| "downranked" means. Google required AMP in order to be
| featured in the "Top Stories" carousel that was
| (unsurprisingly) at the top of the results page. Google
| ended this requirement in mid 2021, https://www.theregister
| .com/2021/06/28/google_amp_core_web_v...
| charcircuit wrote:
| I'm talking about search rankings and not what appears in
| the OneBox.
| lozenge wrote:
| Doesn't really matter. Google directed clicks to the AMP
| sites in various ways, including the OneBox. Most sites
| which need ad revenue had no choice but to adopt AMP.
| Eric_WVGG wrote:
| AMP is a misplaced principle, because it says "due to the
| constraints of mobile, web pages should be lightweight, not
| overdo it on interactivity, and load fast."
|
| Instead they should have said, "Web pages should be lightweight
| not overdo it on interactivity, and load fast."
| neuroelectron wrote:
| Everything Google has done in the last 20 years has made the web
| worse.
| jefftk wrote:
| This is just obviously false. If you want to claim that
| Google's impact has been on balance negative we can certainly
| argue about that, but some clearly positive things include:
|
| * Massive security improvements, including encryption (pushing
| HTTPS throughout the stack, funding Let's Encrypt, trackers on
| HTTPS adoption), site isolation, Project Zero, certificate
| transparency, pushing CSPs, authentication standards.
|
| * Large speed improvements, including V8, HTTP/2, HTTP/3,
| Brotli.
|
| * Web standards, including work on HTML5, JS standardization,
| web assembly, CSS flexbox and grid, webrtc.
|
| (Disclosure: I worked on web stuff at Google 2012-2022)
| nottorp wrote:
| > pushing HTTPS throughout the stack
|
| Barriers to entry for self hosted sites. Easier to host with
| Google now.
|
| > Large speed improvements, including V8, HTTP/2, HTTP/3,
| Brotli.
|
| HTTP/whatever was done only for Google's benefit.
|
| > Web standards, including work on HTML5, JS standardization,
| web assembly, CSS flexbox and grid, webrtc.
|
| If they're so standard why do people develop for Chrome and
| ignore other browsers?
| jefftk wrote:
| _> Barriers to entry for self hosted sites. Easier to host
| with Google now._
|
| Let's Encrypt (which Google helped fund) is the opposite of
| a barrier to entry. Free domain-validated fully automated
| HTTPS cert distribution wasn't a thing, and now it is. It
| makes it way easier to self host in a post-PRISM world.
|
| Also, Google does a tiny fraction of overall web hosting.
|
| _> HTTP /whatever was done only for Google's benefit._
|
| Your claim is that everything Google has done has been
| worse for the web, so you don't get to pick individual tech
| that's clearly good (ex: V8) and ignore it. And whether
| things were done for Google's benefit is also irrelevant:
| the claim is about outcomes.
|
| On the specific question of HTTP/2 and HTTP/3, these have
| made large improvements in end-to-end loading times across
| the web, including when Google is at neither end of the
| connection, and especially for high latency connections
| like mobile.
|
| _> If they 're so standard why do people develop for
| Chrome and ignore other browsers?_
|
| All of the things I listed are widely supported and fully
| standardized.
|
| There are other parts of the web platform that aren't, and
| that does push people to Chrome, but that's not what we're
| talking about.
|
| Again, if you'd like to claim Google's impact has been bad
| on net that's much more arguable, but your claim is way
| stronger than that.
| nottorp wrote:
| > Free domain-validated fully automated HTTPS cert
| distribution wasn't a thing, and now it is.
|
| Free _compulsory_ ...
| warkdarrior wrote:
| It is not compulsory. The browser may warn about lack of
| HTTPS, but that's about it.
|
| And I won't visit such HTTP-only site since it indicates
| the site owner does not care to protect my (meta)data,
| but they probably don't want my clicks.
| nottorp wrote:
| And would you think this way if they didn't spam the
| "accept the risk and continue" scareware?
|
| Why is it phrased as the risk is coming from the web
| site, when the risk actually comes from the backbone and
| whoever is able to intercept your communications?
| cookie_monsta wrote:
| (paraphrasing from memory because it's a while since I've
| seen it)
|
| > Your connection is insecure. Information you send could
| be intercepted by attackers. Accept the risk and
| continue?
|
| Explains the problem in simple terms. Calls out the
| website for being lazy and careless. Gives you the option
| to proceed if you don't care.
|
| Why is this scareware and how would you word it?
| charcircuit wrote:
| >If they're so standard why do people develop for Chrome
| and ignore other browsers?
|
| Because in practice each browser is a separate app platform
| with support of different features and with different
| performance profiles. From a business perspective for a
| business to expand to a new app platform there must be some
| sort of justification to do so. As an extreme example think
| of why don't websites also remake their site on Roblox for
| example? Supporting a product on an app platform well is
| expensive and not all platforms can justify that expense.
| nottorp wrote:
| But ... i thought Google was standardizing the web.
|
| Would they be introducing features to their browser at a
| speed no one else can match just to create a lock in
| effect instead?
|
| And are those features benefiting every site or are they
| targeted towards Google properties?
| charcircuit wrote:
| They are standardizing the web.
|
| >just to create a lock in effect instead?
|
| No, developers requesting features and expressing pain
| points are a major motivator of changes.
|
| >And are those features benefiting every site or are they
| targeted towards Google properties?
|
| They are targeted towards web developers to enable them
| to create good experiences for end users.
| neuroelectron wrote:
| The way that monopolies dominate is by stagnating tech. IT
| tech. The driver of our economy. You're missing a decade plus
| of killed advancements through acquisition and extermination.
| The efficacy gains are theirs, we just get to larp as being
| better by using them. The idea that HTML5, JS
| standardization, web assembly etc. are important is ignoring
| how they are simply abstractions that maintain the status quo
| and add complexity that only serves builds their moat.
|
| RSS is probably the best example. This is massively more
| efficient than any other thing you mentioned, which are only
| incrementally better. RSS saves orders of a magnitude more
| energy than is "saved" by modern JS which requires ever more
| powerful processors where older computers are simply
| incapable of browsing the modern web, but for some legacy
| websites which really highlight how "efficient" these techs
| you mentioned really are. The only thing they are efficient
| at is extracting money from users into Google's pockets and
| selling new iPhones.
|
| Newer processors, massive low power RAM banks, specialized IP
| processors, cutting edge lithography, Webkit, Chromium, all
| these advancements google now claims as theirs with your
| logic.
| rchaud wrote:
| This article misses the point of why emails were made interactive
| in the first place - to satisfy the demands of marketers. 90% of
| the emails you get are marketing-related. If you get an email
| that says "4 days left for our holiday sale", that counter will
| need to be updated if the email is not read on the same day. It's
| a small, maybe frivolous-sounding use case, but a lot of feature
| bloat starts out this way.
| Nazzareno wrote:
| You can do much more with AMP, not only marketing related
| stuff. Indeed, countdown timers can be done much easier with
| many tools (Nifty Images, Sendtric etc) without AMP.
| rchaud wrote:
| AMP as described in this article provides a wrapper for some
| templated kinds of JS functionality. My comment wasn't
| specific to AMP, it was to the article's main point about
| "interactive emails" being unnecessary.
| BiteCode_dev wrote:
| You don't need interactivity for this, you just need "<img
| src="" />"
| dawnerd wrote:
| Which still isn't perfect as images get cached at different
| stages depending on the email client.
| johannes1234321 wrote:
| Or can be blocked or are opaque to visually impaired.
| epc wrote:
| Netscape tried dynamic email with Communicator in the
| 90s...somehow I still have the sample "Airius Airway's 401k
| Contributions Worksheet" with JavaScript embedded (Gmail
| obviously ignores it). IIRC no one, and I mean no one, took
| advantage of it.
| h1fra wrote:
| When AMP was about to be released, I was the engineer in my
| company in charge of deciding whether to implement it. I
| discarded the idea, but months later we realized Google was not
| joking about the SEO boost, and we had to backtrack very quickly
| in order to not lose to the competition. I regretted saying no
| because I missed the opportunity, but I was still convinced it
| was a bad idea overall.
|
| Now that it's gone, I could not be happier. Not only did AMP made
| the internet worse, but it was a pain to implement, a bad
| experience for users, and a bad deal for media companies.
| faust201 wrote:
| AMP was a boon to all crap sites built by S Asian newspapers etc.
| even FT, guardian at some point had individual pages that were
| about 50x larger than it's AMP equivalent. Yes, for the rich AMP
| is monopoly etc. for poor like me - I prefer less data usage.
| hughw wrote:
| Google Wave (ca 2009) also claimed that it would replace email.
| Expect the next email replacement from Google in 2029.
| rhet0rica wrote:
| I came looking for this comment. One wonders if AMP-in-email
| was a project of the same team scaling back their original
| ambitions... but 10 years is a long time at the revolving door
| of Google.
| Nifty3929 wrote:
| To me the most important objection is that an email is a record
| of something, and needs to be self-contained and immutable for
| that reason.
|
| When I get an email, I want to know that I can always come back
| to that exact email for reference, and that there's no way that
| it can have changed, or that the important information is
| externally referenced (and therefore also subject to change).
|
| I think this is one important reason that more and more emails
| are just links to some website with the information on it (often
| with a login required as well). It allows the company sending you
| the email to retain control of that information. If you email me
| a text or PDF invoice, I can always come back to it for my own
| reference. If you send me a link to one, there's no guarantee I
| can still access it later.
| LoganDark wrote:
| > I think this is one important reason that more and more
| emails are just links to some website with the information on
| it (often with a login required as well).
|
| I hate this with all of my being. It's awful. Send me an email
| that tries to tell me how important the information is without
| actually giving me the information... and I won't read it, fuck
| you. You don't get to decide which information I find
| important.
| xp84 wrote:
| I agree wholeheartedly -- it's like getting a postcard saying
| "You have an important message from your doctor, go visit the
| doctor's office to find out what."
|
| I respect that some of this is ass-covering because of
| overreaching regulation (or in many cases probably overly-
| conservative readings of the vague regulations) especially
| with respect to HIPAA and Euro-style "Privacy" legislation,
| but personally I'd prefer to opt-out of all types of nanny-
| ism trying to 'protect my privacy' by sending me content-free
| email with links, that then require that I 'click to view'
| and then, 90% of the time now, return to my fucking email to
| retrieve a stupid code.
| LoganDark wrote:
| My doctor does it ("you have one new notification, log into
| our system to see it"), financial systems do it ("something
| something happened on your credit report, log into our
| system to see it"), legal systems do it ("you have
| something something communication, log in to download it"),
| etc. It's utterly infuriating.
| SoftTalker wrote:
| Some of these places are between a rock and a hard place.
| HIPAA or other rules may prevent a doctor from using
| email to send you personal medical information such as
| test results. For any of them, email isn't "secure" and
| they don't want to be accused of "leaking" personal or
| confidential information.
|
| GPG exists, but it's been a non-starter for the average
| user the entire time, so no reason to expect that it will
| suddenly become workable now.
| briHass wrote:
| Ironic, because it's assumed your email is insecure and
| visible to more than just you, but it's used as a
| password reset and/or 2FA mechanism for almost
| everything.
|
| It would be nice if sites had a checkbox that allowed you
| to affirm that your email is secure and private, so then
| detailed emails were sent.
| SoftTalker wrote:
| There's no way to guarantee that. SMTP is not a secure
| protocol. Your message could be read by any intermediary
| along its delivery route.
| grayhatter wrote:
| It is possible to deliver emails IFF the receiving server
| presents a valid TLS connection and cert. I don't think
| I've seen anyone actually enforce that though.
| SoftTalker wrote:
| Yes but the server itself has full visibility on the
| message while it is handling it. It can scan it for
| viruses, parse it for ad insertion, feed it to train an
| LLM, just keep a copy of everything, whatever.
| grayhatter wrote:
| yeah... that's why it's important to be able to trust
| your email provider... I assumed you meant anyone passing
| along the message, like a router, or rogue ISP. I was
| more going for the idea that you can make SMTP secure
| from sender domain to destination domain. If you don't
| trust your host, nothing else really matters, in all
| cases.
| kevin_thibedeau wrote:
| SMTP can use intermediate relays. TLS doesn't guard
| against the middlemen.
| grayhatter wrote:
| When I suggested using TLS, signed by a trusted cert
| authority; and you're imagining some system, where a
| message sender connects to some 3rd party middleware box
| to relay the message, and this middleware box has a cert
| for the destination domain?
| AStonesThrow wrote:
| > HIPAA or other rules
|
| Sure, sure, rules, yeah.
|
| But there are plenty of reasons that are as numerous as
| reasons to build a walled garden.
|
| If they're storing your records, then they control the
| audit trail. They detect every time you, or someone,
| visited that site, logged in, viewed pages, downloaded or
| viewed a document, changed settings, updated profile,
| added contact info, deleted contact info.
|
| They control the expiration and retention periods. They
| control the file formats. They control the uptime and the
| downtime. They control the horizontal and the vertical.
| Oh wait, that's on T.V.
|
| There will be increasing gauntlets to run and obstacles
| and hurdles to the consumer getting our hands on
| documents and information. Until we really need that
| proprietary online viewer to open the file at all. Or at
| least their mobile app. Or you could pay fees for records
| access. It costs them to store it all, does it not?
| SoftTalker wrote:
| Absolutely those things are all valid concerns. But even
| if they are not doing those things, email is problematic
| for delivering confidential information.
| LoganDark wrote:
| It could also be that they want to know when some
| communication has been received (by the real person, not
| the email server) and that's not possible with email. I
| still maintain that I hate that practice because I just
| don't want anyone to have that information, I want to be
| invisible.
| l72 wrote:
| I would happily go into my bank or medical provider and
| upload my pgp public key for them to encrypt emails with...
|
| Email is an incredibly important communication database and
| I expect my important communications to be there and be
| searchable.
| ChuckMcM wrote:
| I believe this is _exactly_ correct. Email is a 'paper trail'
| and being able to change that paper trail ex-post facto
| benefits the sender _waaaaaaaaaaay_ more than it does the
| receiver. I met an engineer from Google who quit when they
| insisted on "dogfooding" this.
|
| They used the example, you send an email that says lets meet
| for dinner tonight at 6. You arrive and after 30 minutes begin
| to wonder, go back to your email and now it says meet "tommorow
| night" at 6. Are you crazy? Did you misremember? Or did the
| sender change the email after they sent it and you read it? How
| could you complain?
|
| As I understand it, it was met internally with "that isn't what
| we mean." But the ability to send HR important announcements
| and then change them after the fact is a capability that is
| just too tempting for HR to resist at some point.
| parl_match wrote:
| > They used the example, you send an email that says lets
| meet for dinner tonight at 6. You arrive and after 30 minutes
| begin to wonder, go back to your email and now it says meet
| "tommorow night" at 6. Are you crazy? Did you misremember? Or
| did the sender change the email after they sent it and you
| read it? How could you complain?
|
| This is a calendar invite. And this is a completely valid use
| case, but it's useless if I don't have an edit log. It's
| crazy how many people miss that last part.
| ChuckMcM wrote:
| In current email you get ANOTHER email that says the invite
| has been updated. While it changes "automagically" on your
| Calendar. That second email is critical.
| 5- wrote:
| when i was forced (thankfully, briefly) to use outlook
| (web version), one of the big surprises was that rsvp'ing
| on the invite deleted the message.
|
| several times i came looking for that invite and felt
| gaslighted not to have it in my inbox.
| cookie_monsta wrote:
| That's just a setting, turned on by default annoyingly
| albert_e wrote:
| Absoutely agree,
|
| Gmail started scraping all emails a decade ago. Amazon
| responded by removing all product and pricedetails from Order
| confirmation and Order shipping emails. We consumers lost out
| -- we dont have our own copy and archive of what we ordered. If
| Amazon links perish to link rot and we lose access to Amazon
| login, our past order and spend information is gone.
| joshstrange wrote:
| When reconciling my budget (with YNAB) I often use gmail as
| my way to connect items to transactions [0]. I've found that
| I can just search for the amount that my card was charged in
| my email and find the Amazon email that relates to that
| order. Then, normally from the body, there is just barely
| enough information for me to know what I bought.
|
| That got annoying enough that I just wrote a chrome extension
| to scrape Amazon orders/transactions and auto-match and
| update my YNAB memo line with a summary of the items.
|
| That's a bit of a tangent just to say: yes, they nerfed their
| emails but not completely.
|
| [0] Yes, YNAB recommends that you enter transactions right as
| you make them, but that's not how I use it.
| mattzito wrote:
| FWIW, as far as I'm aware, it wasn't gmail scraping that was
| the cause of Amazon pulling that information. It was third-
| party plugins that read people's inboxes to provide them with
| coupons, discounts, etc., and those companies would sometimes
| sell the pricing data. I assume Amazon wasn't thrilled about
| that, but there wasn't anything they (or gmail) could do
| about it as long as the user was granting them access to
| their inbox.
|
| But also - I just ordered something off of amazon and I
| noticed that the confirmation had the item that I ordered in
| it, albeit in a shortened/summarized way? So maybe they
| brought it back, figuring that with just part of the name,
| there's not much someone can do with the pricing information?
| Or maybe they just don't care anymore?
|
| (disclosure: I work at google, but not on this, but worked
| adjacent to the gmail team for a few years and am going off
| of my memory. I'll also tap the sign that Google doesn't mine
| your gmail for ads, for both consumer AND paying customers).
| kevin_thibedeau wrote:
| Gmail has always scraped emails. That was in the TOS from day
| one. Your data was the price for the free service.
| lozenge wrote:
| They stopped doing that in 2017.
| mcv wrote:
| > more and more emails are just links to some website with the
| information on it (often with a login required as well)
|
| And a 2FA SMS sent to your phone.
|
| > If you email me a text or PDF invoice, I can always come back
| to it for my own reference. If you send me a link to one,
| there's no guarantee I can still access it later.
|
| Download it. It sucks having to do that and maintaining your
| own archive instead of trusting your mailbox, but I guess
| there's some advantages to that as well.
| m463 wrote:
| > immutable
|
| I swear years ago I had a mail client where you could type into
| a received message and alter it. Maybe sun mail or early apple
| mail?
|
| they finally made the message pane immutable.
| andirk wrote:
| I remember AOL email to AOL email had an "unsend" feature for
| a while.
| maronato wrote:
| Does anyone remember PlutoMail[1], the client that let you send
| self destructing and editable emails?
|
| [1]: https://techcrunch.com/2014/06/18/pluto-mail/
| mschuster91 wrote:
| > I think this is one important reason that more and more
| emails are just links to some website with the information on
| it (often with a login required as well).
|
| That's an unfortunate requirement these days.
|
| For one, in Europe concerns around GDPR: e-mail is not
| guaranteed (!) to be encrypted or protected against
| modification in transit so it might get snooped up on its way,
| which makes it a no-go for sensitive stuff such as healthcare
| information or other highly protected classes of PII, unless
| PDF encryption or other ways of encryption are used... but
| these have the issue that UX around many of them is horrible. A
| link to a portal however? Easy, and provides automatically the
| guarantee that the other person is who they claim to be.
|
| The second problem is deliverability: more than enough email
| providers still have laughably low limits (sometimes < 3MB),
| virus scanners don't like PDFs or ZIPs that they can't read
| (because they don't know the password, obviously), and on top
| of that come the usual anti-spam concerns.
|
| IMHO, the best way to go would be an extra header field, think
| like "X-External-Attachments: https://foo.com/<uuid>.pdf <hash-
| alg> <hash-value>"... this could be used by MUAs to prompt the
| user if they wish to download and store the file, provide
| cryptographic checks of the file, and sidestep the issue of
| dumbass middleboxes yeeting password-protected files, as the
| files can be scanned on the endpoint side.
| rajnathani wrote:
| But with remotely loaded img tags (automated emails don't send
| images as static base64) that email is far from an immutable
| paper trail like how a PDF is.
| 0xbadcafebee wrote:
| "Interactive email" is basically Slack.
|
| We should make Slack a new internet protocol and application
| standard, and use that going forward to replace e-mail, texting,
| and the various isolated islands of "secure chat" solutions
| (WhatsApp, Signal, Telegram, etc). Allow us to retain and control
| our own data, while also enabling all of the features and
| functionality we've come to want from modern tools, _and_ be
| compatible with other solutions.
|
| IRC and e-mail are both old and busted. 99% of the world wants to
| communicate and share information with more interactive tooling
| than ASCII text in a console or static HTML in a mail reader.
| There are alternatives to Slack, but like every networked
| application created in the last 10 years, none of them define an
| interoperable standard. They are all their own vendor-lock-in
| islands.
|
| Even Mattermost, the most polished "open-source" alternative, is
| not a standard, it's an application. Applications change all the
| time. Standards don't. Applications lose backwards compatibility,
| change their licenses, have closed ecosystems of servers.
| Standards don't. There's a reason that actual standard network
| protocols continue to work for 40 years, while applications made
| just a few years ago are dead and buried. Standards last. They
| enable interoperability in an ecosystem of supported technology.
| They give us flexibility, choice, competition, portability. The
| world is better when we have solid standards to build on.
|
| Replace it all with a standard. Let anyone implement the
| standard, implement a client, a server, etc. And let people
| choose the tooling they want - but while being _interoperable
| with everyone else 's_.
|
| (Note that I'm _not_ talking about federated social networks.
| E-mail and IRC are not social networks, they are communication
| tools, private by default, and have to be directed at specific
| individuals or groups)
| watermelon0 wrote:
| I think that you just described XMPP and Matrix, which are both
| standards.
| 0xbadcafebee wrote:
| Comparing XMPP/Matrix to Slack is like comparing Telnet to
| Chrome. Yes, they both display text, they're both
| interactive. But the latter has about 5,000x more features,
| which is why we all use it.
|
| Yet with Slack, it doesn't use a standard. _Could_ you build
| an app like Slack that _includes_ XMPP /Matrix along with a
| whole lot of other stuff? Sure. But without the whole kitchen
| sink, you still don't have a standard other apps will follow.
| You have a proprietary app _plus XMPP_. Other apps won 't be
| compatible with it. Which is the case with Slack's
| competitors.
|
| Think of a web browser. It's larger than a kernel. It's
| probably the biggest, fattest, meatiest, most feature-rich
| application in the world. (And it should be, because it's a
| freakin' application platform at this point.) But it all runs
| on.... _standards!_ Every part of it. I 'm saying, _do that_
| , but for the massively feature-rich, complex, large, almost
| unwieldy, but insanely productive, communications platform
| that is Slack.
|
| I get that a lot of people don't really understand what the
| big deal about Slack is. A lot of people thought the same
| thing about web browsers back in the day. But once they
| started using them a lot, they got it. It's not just a
| document viewer, just like Slack isn't just chat.
| nottorp wrote:
| Slack is basically irc with some bells and whistles, sorry :)
| nightpool wrote:
| It really, really isn't.
| iaabtpbtpnn wrote:
| You want THE communication standard to be owned by Salesforce?
| marcellus23 wrote:
| > Replace it all with a standard. Let anyone implement the
| standard, implement a client, a server, etc. And let people
| choose the tooling they want - but while being interoperable
| with everyone else's.
| layer8 wrote:
| Slack is chat, and chat is not email. Email has important
| properties that are lost in a chat protocol/UI.
| lern_too_spel wrote:
| XMPP exists as a standard, and Google Chat was built on it.
| Then Google+ came along and needed more features, and instead
| of adding these features to a standard that supports federation
| (like XMPP or now Matrix), Vic Gundotra (I assume) did the
| expedient and stupid thing of building Hangouts Chat like
| Facebook Messenger, commencing the parade of throwaway Google
| communications products to come.
| ChrisArchitect wrote:
| This is a weird thing to write about in 2025. AMP emails didn't
| really take off / get any kind of adoption did they. And HTML
| emails, annoying and problematic as they are have come a long way
| from the mess of client support and complete hack-job coding to
| where they are now thanks to standards and largely the popularity
| of web-based clients and the benefits those bring for email
| reading. GIFs inside emails unthinkable and ridiculous ten years
| ago. Today, not a big deal really for a good chuck of audiences.
| Etc.
| kotaKat wrote:
| I do remember using WorkMarket a long time ago and experiencing
| the bizarreness of their emails as they were one of the very
| few AMP users.
|
| They'd send out emails about work opportunities and leveraged
| AMP to be able to go back into the email and tell you if it's
| still available to apply for or not in realtime, so you
| wouldn't have to click through and be disappointed it was
| already taken.
| robertoandred wrote:
| On the contrary. The only place you get a standards-based email
| is Apple Mail on Mac and iOS. Gmail's web client is absolutely
| terrible for web standards. Outlook, on the web or app, is
| almost as bad.
| Digit-Al wrote:
| Email and SQL: two technologies that people keep saying are out
| of date and need replacing, but they keep rolling on whilst
| attempted replacements wither on the vine, with their dust
| eventually blowing away on the winds of time.
| skybrian wrote:
| Meanwhile, many people don't send personal emails anymore and
| people have switched to a variety of chat apps instead. And a
| lot of businesses use chat internally, such as Slack.
|
| It's mostly business use that's keeping email alive, either
| business-to-consumer or business-to-business.
| throwaway28692 wrote:
| So frustrating when people complain about Google trying to save
| dying technologies like email and the web. I'm glad that email
| is working for you but over here in the real world I don't know
| anyone who still uses it.
| nottorp wrote:
| IMO any standard pushed by the great internet gatekeepers
| (Google, Cloudflare etc) is best avoided.
|
| And don't tell me Cloudflare does no evil, that goes for now, and
| that went for Google some time in the past too.
| LinuxBender wrote:
| I've never received an AMP email but it looks like based on the
| format [1] one could search the body for _cdn.ampproject.org_ and
| either REJECT, DISCARD in Postfix or quarantine it if using some
| anti-spam platform. # grep body main.cf
| body_checks = regexp:/etc/postfix/body_checks # grep
| ampproj /etc/postfix/body_checks /ampproject/ REJECT
| AMP IS NOT SUPPORTED ON THIS SERVER
|
| [1] - https://amp.dev/documentation/guides-and-
| tutorials/learn/ema...
| albert_e wrote:
| > Four years earlier, the search giant had come for the mobile
| web with AMP--accreted mobile pages.
|
| typo in third line of the post.
|
| should i feel warm and fuzzzy knowing that this was not run
| through an LLM?
|
| or is it a hallucination artifact of that very thing.
| account-5 wrote:
| I didn't know amp was a thing in email. Glad it died before I
| knew about it.
|
| I've never viewed an amp site either. Actively avoided them, went
| out my way to view the actual content. Easy to do when you don't
| have JavaScript enabled by default. I hate it when I can't view
| textual information on a site without JavaScript.
| _Algernon_ wrote:
| The worst part about AMP was that it didn't even feel
| particularly fast. Not sure how they managed to fail at literally
| their main design goal.
| ingvar77 wrote:
| I think it was a great idea, useful in many cases (confirmations,
| approvals, votes, unsubscribes, forms, up-to-date flights and
| bookings info etc etc. I for sure admire that I can accept
| meeting invites right inside email in Gmail. Email must stay the
| same - it has HTML/text parts, these will stay same and can be
| accessed in 5 years. If someone really wants to include dynamic
| info in email they will do anyway- either link to webpage or
| dynamic image.
| gregable wrote:
| I worked on AMP and AMP email for a while at Google, but these
| are just my thoughts. HN always pulled out the pitchforks on this
| topic, I'm not surprised to see the same again. I disagree with a
| number of things this article claims:
|
| > Build an AMP site, and you'd get preferential placement in
| search results ... The implicit stick, though, was that without
| an AMP page, your site wouldn't rank as highly as it may have
| previously. And
|
| There was an AMP news carousel that would appear at the top news
| results. The web result order however didn't prefer AMP.
| Depending on how you looked at it, this was preferential or it
| wasn't. The "wasn't" perspective is that this carousel was much
| like showing image or video results - it was a different format
| and there was a result spot reserved for some docs of that format
| if the query warranted it.
|
| Interestingly, when Google first started rolling out carousels
| for images or videos in normal results, website owners protested
| as well as it was competition for visibility. I don't hear that
| argument as much any more.
|
| Regardless, the AMP carousel has been gone for a while AFAIK.
|
| > "We are here to make the web great again," said Google's vice
| president of news, Richard Gingras in 2015, only months after
| Donald Trump brought that phrase into the vernacular
|
| Yeah, that aged poorly.
|
| > [AMP] brought back the dynamics of the mobile versus the
| desktop web, for one. Instead of the same web for everyone, you
| now had one page on mobile, another page on desktop
|
| That was a website owner choice. AMP pages could be responsive
| and work just fine on desktop. Many sites did exactly that,
| though you often never realized they were AMP pages. The goal of
| the project was always to optimize mobile performance, but it
| worked well for desktop too. Search provided a mechanism where
| you could choose to pair an amp and non-amp page, only showing
| AMP for mobile. I suspect sites did this because non-amp allowed
| all of the bespoke javascript they wanted on desktop, including
| things that were kinda terrible for user experience but improved
| ROI. Super heavy javascript, ads that were difficult to dismiss,
| all sorts of jank.
|
| > And, more critically, it lessened your control over your site.
| ... ad tech and other scripts on your site might be incapable of
| running on your AMP site
|
| AMP is a subset of HTML plus some javascript libraries. The
| subset thing means you had a limited API. That was the point
| though, the limited API was restricted to the set of things that
| could be forced to be performant. That is "control" in some
| sense, but it wasn't control in the common sense of limiting
| content or ad networks or whatnot. Virtually every ad network had
| a library for running on AMP.
|
| > AMP required allowing any AMP CDN to cache your pages.
|
| You can and always could create amp pages that are not served by
| AMP CDNs. The tradeoff is that search results couldn't preload
| the page for the user, as there is a hard privacy constraint that
| the user can't initiate network traffic to the publisher until
| they indicate intent with a click. So without the CDN, it wasn't
| quite as fast, but it was still typically pretty fast.
|
| > As Ray Tomlinson, who implemented and sent the first email from
| ARPANET in 1971 said about adding formatting to email: "That's
| too complicated: we just want to send messages to people."
|
| This is a valid perspective on what email is or should be. I
| don't feel strongly that it's the only perspective, but it's
| certainly valid. The argument however is really against HTML
| email, not AMP email in particular. I think most of the rest of
| the arguments apply pretty equally to both.
|
| If you look at HTML email in webmail clients, clients all work on
| the principle of sanitization. Take arbitrary HTML, modify it to
| remove anything dangerous, and then render the rest. "anything
| dangerous" requires removing all javascript, most or all CSS,
| large swaths of the HTML tag space, rewrite all image URLs, etc.
|
| This would result in pretty garbled results except senders have
| adapted to only send the subset of HTML that won't be garbled.
| However, it's not easy to do. Take a look at
| https://templates.mailchimp.com/resources/email-client-css-s...
| which shows what each email client accepts. It's much much worse
| than browser incompatibility, though you also have to handle
| browser differences too.
|
| In a sense, this limited HTML API is similar conceptually to AMP.
| AMP just was able to add back some of the interactive
| functionality stripped away. And AMP had the possibility of
| becoming a open-source standard compatibility API for webmail
| clients. One that was open source, had maintained validators that
| could be tested against, etc.
|
| I think it had the chance to really make HTML email better. Of
| course, if your perspective is that HTML email is fundamentally
| bad, then that's not really a win.
|
| > You'd need to authenticate your domain with DKIM, DMARC, and
| SPF--good ideas, regardless. You'd also need to send a sample
| email to both Google and Yahoo!, and register your domain with
| each of them. Then, if you were lucky, within 5 days you'd be
| approved to start sending AMP emails.
|
| I think the plan was always originally to expand this to a
| general availability format. However, AMP email launched in 2019
| and Google largely shifted away from AMP shortly thereafter, so
| the project never got enough momentum to get to that state, sadly
| IMHO.
___________________________________________________________________
(page generated 2025-04-18 23:00 UTC)