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

31–40 of 66 posts

Re: Client-side content encryption

#31

Post by fastball »

hlandau wrote: post #28
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…

But... that actually doesn't apply here? In fact, it's the exact opposite of what you are saying.

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.

Re: Client-side content encryption

#32

Post by dogma1138 »

noizejoy wrote: post #8

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

I wonder if for people with data caps can this be a case for a class action.

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.

Re: Client-side content encryption

#33

Post by contravariant »

mirimir wrote: post #22
jeremiahlee wrote: post #20

Earlier quoted context omitted.

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?

It's answered in a rather roundabout way on their FAQ page for for membership accounts [1]:

>Can I use cryptocurrency to pay for my membership?

>No, all memberships must be paid by credit card in US dollars.

[1]:https://help.coil.com/accounts/membership-accounts

Re: Client-side content encryption

#34

Post by fastball »

diggan wrote: post #17
marcus_holmes wrote: post #14

Earlier quoted context omitted.

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?

The same content is being served to Googlebot and users with this solution... unlike before.

Re: Client-side content encryption

#35

Post by kreetx »

It appear that sending encrypted content is a bet on whether the user pays for the content or not. I'd wager that for most page loads people won't go on to pay. So if page-loads become larger on average due to the encrypted content then the real benefit here is that the original content providers will be hit less (since amp can fetch the content all at once), but perhaps more importantly, google can index this content.

edit: So in total, users' bandwidth won't be saved - google is just serving itself, but packaging it as a user benefit.

Re: Client-side content encryption

#37

Post by fastball »

contravariant wrote: post #33
mirimir wrote: post #22

Earlier quoted context omitted.

What forms of payment does Coil accept?

It's answered in a rather roundabout way on their FAQ page for for membership accounts [1]: >Can I use cryptocurrency to pay for my membership? >No, all memberships must be paid by credit card in US dollars. [1]: https://help.coil.com/accounts/membership-accounts

So not a solution for content likely to be censored or adult content.

Seems like BAT is still the way to go.

Re: Client-side content encryption

#38

Post by mirimir »

contravariant wrote: post #33
mirimir wrote: post #22

Earlier quoted context omitted.

What forms of payment does Coil accept?

It's answered in a rather roundabout way on their FAQ page for for membership accounts [1]: >Can I use cryptocurrency to pay for my membership? >No, all memberships must be paid by credit card in US dollars. [1]: https://help.coil.com/accounts/membership-accounts

Oh well.

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.

Re: Client-side content encryption

#39

Post by [deleted] »

p4bl0 wrote: post #18

From 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".

[deleted]

Re: Client-side content encryption

#40

Post by bscphil »

fastball wrote: post #30
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.

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

Post reply on HN