Client-side content encryption
blog.amp.dev
blog.amp.dev
It's actually a software that helps breaking the web for its users. Basically it allows paywalled websites to send users their inaccessible data even of they won't be able to read it. The title should be "DRM for web page that eat up your data plan even if you can't access the content".
Websites could have done this before as well, and many in fact already do. It's generally established pattern in webdev if you need to be able to unlock content in a fast manner, without having to request additional content from a backend. Notably, many P2P networks works the same way regarding private-but-still-distributed content as well.
I really hope AMP never gets any large scale adoption by consumers.
Sad part is that with Google's marketshare on smartphone (StatCounter shows 77% of mobile OS is android) and web (again, StatCounter: 63% on Google Chrome) they don't need consumers to adopt it. They just make to need any alternatives (like not using AMP) be more of a hassle and normal users will just use it, not considering the consequences.
(I use Firefox and occasionally Safari on mobile, so I've no idea here).
AMP is however not just that, it's also the AMP Caches, which are currently gatekept by Google and CloudFlare with little information published around how you run your own. There is just some guidelines, but no information outside of that. This is the part that many are feeling is giving Google too much control and influence over the web, as they control large swaths of the web and are now trying to find ways of making sure people don't leave their controlled parts.
But results like this seem to be commonplace now, with Google doing nothing about it. This article seems to be overt confirmation that Google no longer has an issue with this. Sad to see, though of course Google jumped the shark a long time ago.
Google isn't encouraging anyone to deliver different results to Google. It is providing a solution that serves the same content to all users (and search engines). That is exactly the thing you said they were espousing previously.
Previously, the actually worthwhile solution to paywalling was to not load the content at all until after auth. This means that you were showing different content to a google spider vs. a subbed user. Now it's the same.
Encryption is not changing content, in fact it's the only way to prove that the content was not changed from the version google indexed vs what your are seeing.
Please correct me if I am wrong, but google has always indexed paywalled sites, in other words there has never been a guarantee you have rights to view what google indexed. The only sin is to say "I told google I have A" but really you have B.
It seems like what you are arguing is that google should not index paywalled sites. This is a legitimate desire of course, but has never been reality.
(Also, this was my first comment in this thread)
https://searchengineland.com/google-first-click-free-replace...
Yes it is changing the content. From the point of view of Google's web crawler, the content is decrypted automatically and it sees, and indexes, the true page. From the point of view of my client, which is not signed into the paywall, I see an encrypted blob that I can't do anything with unless I sign in.
This is, of course, the point that everyone is making. Saying "well the content of the blob is the same whether you can view it or not" isn't relevant - the question is whether you can view it.
As someone who is actually subbed to a few paywalled sites, this solution sounds great to me.
I mean, we're talking about paywalled content here – ideals of an Open Web don't really apply.
I think the scenario being imagined here is:
1. I search for story on Google dot com.
2. Paywalled story appears at #1, artificially boosted relative to other paywalled content because Google can index it.
3. I click on the story (not knowing it's paywalled), am greeted with a paywall. The site not only blocked me from viewing the story, they just wasted significantly more of my mobile data.
The monopolisation here is a very scary trend.
If the content is encrypted and can only be decrypted by the user with the right keys, how does Google get to decrypt it? They have a master-key everyone needs to use in order for this to work?
Took a look at https://amp.dev/documentation/guides-and-tutorials/develop/m... which is linked as well, but got no answer.
I seem to remember something around that Google penalized websites who showed different content between Googlebot (the indexer) and a normal website visitor. Does this move go directly against that, when the premium content would be indexed but not be able to be viewed by the visitor?
"You are required to encrypt the document key with the local environment and Google’s public key. Including Google’s public key allows Google AMP cache to serve your document."
So you have to encrypt the document key with their public key so they can decrypt at will. No master key required.
So does that mean that Google will no longer penalize websites that show different content for Googlebot vs normal visitors, or is this "AMP client side encryption" a exception to this rule?
So why not instead come up with a workable micropayment system?
>Can I use cryptocurrency to pay for my membership?
>No, all memberships must be paid by credit card in US dollars.
Seems like BAT is still the way to go.
It is possible to go ~anonymously from cryptocurrency to "paid by credit card in US dollars". Basically you barter cryptocurrency for a credit card payment. You can do it with someone you trust. Or you can negotiate online. But then you may get a stolen card account, which might be embarrassing.
I wonder if they accept gift cards.
I am not looking forward to having bandwidth wasted on this crap.
To be clear I'm a big fan of use of the WebCrypto API in general.
As a small rant I can't stand Amp as a whole, and haven't been using Google services for a few years. YouTube being the begrudged exception; and there I use it 95% in incognito, with frequent cookie flushes outside of incognito. They're capable of tying the shadow profiles together but I'm expecting them not to.
(And on that tangent, I still don't understand why Google ever had the right to buy the .dev TLD for its own private uses.)
Fewer and fewer networks allow more than outgoing 80 and 443 TCP connections. Fewer still allow any incoming connections. The standard way to send email now is connecting to a web site.
Continue like that, and everyone will have to tunnel UDP over HTTPS to get anything done.
Tragedy of the commons, too many people abused their freedoms and attacked other people. These days, having open ports on a machine that is not a dedicated server is asking to get hacked, plus that many providers don't even have enough ipv4 addresses any more to hand them out to consumers.
The only thing that makes this practical is Google's existing know-how of billions of it's users, and offloading of content encryption on server-side using Google's services
edit: So in total, users' bandwidth won't be saved - google is just serving itself, but packaging it as a user benefit.
It's time for a new web, and a new user agent with a minimal core so it isn't impossible to implement.
First, we are doomed from the start, because of network effects. The new web will likely never gain any traction whatsoever, because it looks like backwards compatibility is more important than simplicity, performance, and CO2 emissions.
Second, we must agree what that new web is for. We can display text, images, audio and video. We can tweak the layout of the content. We can take input from viewers (text, uploaded files…). We can make entire applications on top of the web.
Once we agree on the purpose of the web, we need to chose how to make it happen. Do we serve content declaratively, or procedurally? Should browsers be readers of a well defined, limited data format, or should they be virtual machines? I personally prefer virtual machines (unlimited functionality on top of a very simple core), but their natural opacity does have its problems: screen readers, dark mode…
---
There may be a way to break network effects: government web sites. Define a new standard that serve those right, make sure this standard is easy to implement pretty much everywhere (including on old computers with a crappy connection), and mandate that all .gov sites move to that. Also maybe rethink the whole security layer, most notably the PKI.
To move things further, we could possibly use regulations. For instance, we could mandate that banks provides an option to use that new web. We could regulate our way into a critical mass, to a point where common folks can realistically ditch the old web.
The user is also trying to access that content so they probably don't find preloading it aggressive, especially if they're on a low-bandwidth connection and they don't have to load the page twice.
I think there can be a case made that if content is indexable to a search engine and presented to the user as a link if it’s then gated without distinction from links that are not a case be made against google or the content providers.
In reality, this is a major paradigm shift, as it provides a way forward for peer 2 peer hosted content. Imagine that instead of sending the key and providing access, rather your access is based on some other out of band validation system, such that another peer controls your access to their content.
Very exciting, but of course this particular perversion of google with AMP is more abuse of technology, solving a problem of publishers at the expense of freedom of information.
The downside is that now you're sending duplicated content to clients. Turning it into an event that javascript could fire off would solve this; a bot accesses the site and hooks up to the encrypted-content event. The event returns a list of search engines. If the bot's search engine is in the list, it hits a well-known URL with its name, and gets back the encrypted content it can decrypt with its private key.
Just spitballing a few ideas here.
Google wants it's own version of the Internet.... a paywalled modern AOL.