Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Client-side content encryption

blog.amp.dev

Post reply on HN
Print view View original

21–30 of 66 posts

Re: Client-side content encryption

#21

Post by ArtRichards »

While not appreciating the use of encryption to paywall services, ultimately its the responsibility of the content provider. If the author of an article contributes their content to a publisher who uses this method of encryption, thats up to the content creator; and then I would hope sites like this would just stop linking to them.

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.

Re: Client-side content encryption

#22

Post by mirimir »

jeremiahlee wrote: post #20
mirimir wrote: post #7

Earlier quoted context omitted.

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. https://webmonetization.org/ https://coil.com/

What forms of payment does Coil accept?

Re: Client-side content encryption

#23

Post by andy_ppp »

The bastards on the AMP strategy really do want to embrace and extend the web; watch out next for a currency that competes with Libra and is even less free. You can pay per click on the web with Google getting 30%+ and for advertising they will be the only game in town.

Re: Client-side content encryption

#24

Post by anon767 »

kohtatsu wrote: post #6

Woo DRM for websites! Thanks Google!

I think that would have been possible without google's help too. Could someone not just send the content encrypted to the client and after signing in sending the corresponding key to decrypt it? Like by using the relatively new Web Crypto API?

Re: Client-side content encryption

#26

Post by SiempreViernes »

anon767 wrote: post #24
kohtatsu wrote: post #6

Woo DRM for websites! Thanks Google!

I think that would have been possible without google's help too. Could someone not just send the content encrypted to the client and after signing in sending the corresponding key to decrypt it? Like by using the relatively new Web Crypto API?

Sure, but mostly people settle for just not sending the gated content in the first place. The reason for sending people data they can't use is somewhat unclear...

Re: Client-side content encryption

#27

Post by SiempreViernes »

three_seagrass wrote: post #9
noizejoy wrote: post #8

I find it quite hostile to send user inaccessible content down the pipe, thereby cluttering up bandwith and local storage.

Prefetching content is a W3C standard. 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.

Most sites aren't very clear with what is gated content until after you click, so most visitors will get an encrypted payload they can't use and then bounce because they didn't want to pay in the first place. Thanks Google.

Re: Client-side content encryption

#28

Post by hlandau »

WhyNotHugo wrote: post #16

Wow, 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 remember in the early days of Google, it was a big no-no for sites to serve different content to Google than to actual users. Sites caught doing this would be banned from Google, so SEO advice quickly became widespread: don't do this, it will hurt you.

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.

Re: Client-side content encryption

#29

Post by kohtatsu »

anon767 wrote: post #24
kohtatsu wrote: post #6

Woo DRM for websites! Thanks Google!

I think that would have been possible without google's help too. Could someone not just send the content encrypted to the client and after signing in sending the corresponding key to decrypt it? Like by using the relatively new Web Crypto API?

Possible? Sure. Widespread? Unlikely.

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.

Re: Client-side content encryption

#30

Post by fastball »

WhyNotHugo wrote: post #16

Wow, 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.

Is it? Now at least Google can index it and it's faster. The solution most savvy publishers were using before was to not send the content at all to the client, which means that search engines were not able to index it at all.

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.

Post reply on HN