We were discussing with the AMP project tech lead over on GitHub trying to suss out details about governance and the like, and it's even scarier than we thought when it came to AMP4Email: Gmail is implementing AMP in email "the way they want to", and AMP Project is just deciding whether or not they want to support it/publish a 'standard'. I strongly recommend this for reading: https://github.com/ampproject/amphtml/is…
AMP: the missing controversy
41–50 of 143 posts
Re: AMP: the missing controversy
#42Earlier quoted context omitted.
I think we have to participate. It claims to be an open standard; we should participate (or try to participate) in the open standard. The problems AMP solves are real. They will be solved one way or another. I'm hopeful they can be solved in an HTMLite sort of way, not a whatever-Google-does sort of way. So let's think about how to improve AMP, change AMP, evolve AMP, until it becomes something else and something bet…
Am I reading the article right: the browser preloads resources from amp pages from the search page? That's going to be hard to fix in an HTMLLite sorry of way.
Re: AMP: the missing controversy
#43Earlier quoted context omitted.
It depends on the platform, and on ongoing developments in law, regulation, and third-party cooperation (one big way U.S. governments get around their own restrictions is by soliciting (often, paid) data from third parties not bound by such restrictions). Anyway, they may well have this data. Some other data, more likely not. And, even where they may have -- or have access to, this data, retention periods may be sign…
Ok but what is the alternative for online communication?
Email seems fine, if it's your own server and you can keep it secure. Including, secure from some legal argument that they can knock on your door or the data center's and just have a look at whatever they want.
There was a fellow in the UK who used assymmetric keys to encrypt all his inbound email, holding it on the server in encrypted form where the paired key was not on the server but rather available only to his email client.
Then, you have the problem of security in transit. That email doesn't offer, inherently. And most of your correspondents won't use PGP/GPG nor SMIME.
I just had another friend start using WhatsApp. Is it really secure? I don't know. At least, she'll use it.
WhatsApp offers to archive your correspondence to Google Drive. I haven't turned that on.
I've tried brining up Signal with a few friends, but they won't give it the time of day. (Unlike the Washington, DC crowd, who now appear to be flocking to it in minor degree.)
The tool I might use is for SMS/MMS. It used to also offer to archive WhatsApp conversations, but that's been discontinued.
Umm...
https://f-droid.org/en/packages/com.zegoggles.smssync/
It's also on Play.
https://play.google.com/store/apps/details?id=com.zegoggles....
So yeah, this isn't any "big security context". Just my personal stuff. But the default is to put the messages into Gmail. On the one hand, actually convenient. On the other... just, no.
I have a bootlooped Nexus 5x with a bunch of SMS/MMS I never backed up. Including, I now realize, from a friendship that's ended. I'd kind of like to have some of those. So, I'd like to be pro-active with regard to the next phone that's going to crap out on me.
----
P.S. In short, I think I basically agree with you. Decentralized, and under one's own control.
It's just that:
Email doesn't secure the transport, and many people won't secure their messages before transport.
If it's not your own email server, under your control including perhaps physical, law in the U.S. with respect to email designates older messages as quasi-abandoned and "up for grabs".
And I forgot to mention the many posts/comments I've been reading here, about how more and more difficult it's becoming to run your own email server, not just in terms of securing it but also because more and more email providers are shit-canning any emails that don't appear to be blessed by their counterparts.
Anyway, I'm not promoting the idea that I have some particularly good answer. Rather, just food for thought.
Re: AMP: the missing controversy
#44Earlier quoted context omitted.
Just how do you imagine they'd "CDN people's non-AMP content"? There's no mechanism by which they could tell the browser to load nytimes.com but to replace the URLs of random resources with different ones. They'd need to host the actual page on Google.com. And after solving all the problems that doing this introduces, you've pretty much got AMP already.
The same way they're trying to fix this problem with AMP: https://github.com/WICG/webpackage (see also: https://amphtml.wordpress.com/2018/01/09/improving-urls-for-... ) Even if you can't package up and ship all of your traditional site to Google's CDN, you could do most of the burdensome/heavy bits. But then Google doesn't get to control your website and define the way it's allowed to look, which is what AMP is real…
I also can't imagine the amount of shit Google would have taken if they'd started just randomly doing that kind of thing for existing web pages. Instead they introduced a totally new mechanism (i.e. AMP) where the caching was a core concept from the start.
> Even if you can't package up and ship all of your traditional site to Google's CDN, you could do most of the burdensome/heavy bits. But then Google doesn't get to control your website and define the way it's allowed to look, which is what AMP is really for.
But "heavy/burdensome bits" are exactly the things that matter the least for this use case. Ideally they would not exist at all. If they do, they should not be speculatively prefetched.
It'd also mean that these pages are now tied to Google's CDN, no matter what. Have a user click through the link from some other source than a Google search result? They'll still end up loading the resources from them. Is that really what you want?
Re: AMP: the missing controversy
#45We were discussing with the AMP project tech lead over on GitHub trying to suss out details about governance and the like, and it's even scarier than we thought when it came to AMP4Email: Gmail is implementing AMP in email "the way they want to", and AMP Project is just deciding whether or not they want to support it/publish a 'standard'. I strongly recommend this for reading: https://github.com/ampproject/amphtml/is…
Actually I did suggest something to stop it; return a 501 for any email that contains an application/amp+html part (even if it has other MIME parts). Doing this means the sender will have to change their behaviour not the receiver.
My own provider FastMail, has said they of course, can't promise they won't support AMP4Email since compatibility is a major goal of theirs, and I can't fault them for that. (And I significantly appreciate the contribution their blog has made to the discussion on the topic.) I'd love if I had the option to opt into behavior like this though, at least on a personal level.
But if only a few percent of users (or more than likely, a fraction of a percent) are rejecting the mail, it won't dissuade anyone. Companies will pick up AMP4Email so they can push dynamic advertising directly in people's inboxes.
Re: AMP: the missing controversy
#46Earlier quoted context omitted.
You're right, being the kind of citizen you want to be is undeniable a good thing, but it's also undeniably useless. It individualizes a collective problem, thereby being an ineffective solution. The only way to resist power is with collective action that substantially challenges it.
I disagree with your defeatist message and I consider it harmful if spread. Individual action is the foundation of our entire social system. It is not "useless" by any measure. I don't want to use AMP in email so I'm not going to. It's just that easy. What are you doing and what do you suggest the rest of us do? Is voting with our wallets not a thing any longer?
Re: AMP: the missing controversy
#47We were discussing with the AMP project tech lead over on GitHub trying to suss out details about governance and the like, and it's even scarier than we thought when it came to AMP4Email: Gmail is implementing AMP in email "the way they want to", and AMP Project is just deciding whether or not they want to support it/publish a 'standard'. I strongly recommend this for reading: https://github.com/ampproject/amphtml/is…
Re: AMP: the missing controversy
#48We were discussing with the AMP project tech lead over on GitHub trying to suss out details about governance and the like, and it's even scarier than we thought when it came to AMP4Email: Gmail is implementing AMP in email "the way they want to", and AMP Project is just deciding whether or not they want to support it/publish a 'standard'. I strongly recommend this for reading: https://github.com/ampproject/amphtml/is…
Actually I did suggest something to stop it; return a 501 for any email that contains an application/amp+html part (even if it has other MIME parts). Doing this means the sender will have to change their behaviour not the receiver.
You can just as well receive the e-mail and just complain if it's AMP only, or they don't pay attention to the plaintext part, causing issues for you.
Re: AMP: the missing controversy
#49Google can't "simply preload resources of non-AMP pages". Using a CDN means they can get more consistent load times and avoid the inevitable privacy concerns that come with loading 3rd party content the user may never actually click on.
So it's not only possible to do, they've literally been doing it for 5 years now.
Firefox doesn't appear to do prerendering, but it will happily prefetch as well and has since Firefox 23.
AMP's cap on file sizes and other limitations helps these relatively ancient prefetching & prerendering work better, but you don't need AMP to get preloading. Not at all.
Re: AMP: the missing controversy
#50We were discussing with the AMP project tech lead over on GitHub trying to suss out details about governance and the like, and it's even scarier than we thought when it came to AMP4Email: Gmail is implementing AMP in email "the way they want to", and AMP Project is just deciding whether or not they want to support it/publish a 'standard'. I strongly recommend this for reading: https://github.com/ampproject/amphtml/is…
I don't even think AMP is the problem. It feels more like an symptom. So the question really goes as: what's the actual problem? To keep it very short, it really does feel like to be around how the ad revenue works on the web. But maybe I'm just mistaken and I'm missing some pieces of the puzzle.