The article talks too much about the problem, and when it comes to solving it, it gives very shallow information.
Agreed, the technical meat is here: https://amp.dev/documentation/guides-and-tutorials/develop/m...
Client-side content encryption
11–20 of 66 posts
Re: Client-side content encryption
#12The article talks too much about the problem, and when it comes to solving it, it gives very shallow information.
Indeed. Seems there are two articles where this one is about the problem, and this: https://amp.dev/documentation/guides-and-tutorials/develop/m... is about the solution
Re: Client-side content encryption
#13> All content is easily indexed by Google and ready to serve from its AMP cache
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?
Re: Client-side content encryption
#14> All content is easily indexed by Google and ready to serve from its AMP cache 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 some…
from the link you shared:
"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.
Re: Client-side content encryption
#15Wasn't Google's excuse for AMP that it's a "standard" and everyone could use it (other search engines for example)? Now they want to add even more Google-specific crap to further lock it down. Not exactly surprising...
Re: Client-side content encryption
#16Wow, this is just terrible. Sites using this will now be indexed by google, but not by any other search engine, since it's encrypted with a key only google [and subscribers] can read.
I really hope AMP never gets any large scale adoption by consumers.
Re: Client-side content encryption
#17> All content is easily indexed by Google and ready to serve from its AMP cache 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 some…
from the link you shared: "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.
Thanks! I somehow missed that. So there is indeed a master key that Google holds, the private key that the public key matches with is that master key.
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?
Re: Client-side content encryption
#18From the title I thought it would be something along the lines of an NaCl implementation in JavaScript.
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".
Re: Client-side content encryption
#19Wow, this is just terrible. Sites using this will now be indexed by google, but not by any other search engine, since it's encrypted with a key only google [and subscribers] can read. I really hope AMP never gets any large scale adoption by consumers.
> 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.
Re: Client-side content encryption
#20Woo DRM for websites! Thanks Google!
Indeed, just what we needed. /s So why not instead come up with a workable micropayment system?
I am quite excited about the Web Monetization API and Coil’s implementation.