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

61–66 of 66 posts

Re: Client-side content encryption

#61

Post by franga2000 »

three_seagrass wrote: post #58
franga2000 wrote: post #15

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

The authorizor appears to be agnostic, so Microsoft can implement it with Bing's AMP too without Google.

The content needs to be encrypted with the "AMP provider"'s key too, so each of the providers needs to be explicitly supported. The webmaster might go through the trouble of supporting Google and Bing, but I doubt many would bother with any of lesser-known search engines, if those were to adopt AMP.

Re: Client-side content encryption

#62

Post by three_seagrass »

franga2000 wrote: post #61
three_seagrass wrote: post #58

Earlier quoted context omitted.

The authorizor appears to be agnostic, so Microsoft can implement it with Bing's AMP too without Google.

The content needs to be encrypted with the "AMP provider"'s key too, so each of the providers needs to be explicitly supported. The webmaster might go through the trouble of supporting Google and Bing, but I doubt many would bother with any of lesser-known search engines, if those were to adopt AMP.

Maybe, maybe not, but those are still options that are agnostic of Google. This doesn't rope AMP into being any more dependent on Google than it was before.

Re: Client-side content encryption

#63

Post by bscphil »

xnyan wrote: post #49
detaro wrote: post #44

Earlier quoted context omitted.

And before, showing different content to Google than to a random web user was bad.

Repeating the same thing you just said in response to an argument is not an argument. 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.…

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

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.

Re: Client-side content encryption

#64

Post by jeremiahlee »

fastball wrote: post #37
contravariant wrote: post #33

Earlier quoted context omitted.

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.

The Web Monetization API standard Coil is based on does not reveal knowledge of what content is being paid for.

Re: Client-side content encryption

#65

Post by jeremiahlee »

mirimir wrote: post #38
contravariant wrote: post #33

Earlier quoted context omitted.

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.

Nothing stops someone from creating a competitor to Coil that also uses the Web Monetization API emerging standard and that competitor accepting subscriptions in another currency, including crypto. That’s one reason why it’s such a compelling idea.

Re: Client-side content encryption

#66

Post by fastball »

jeremiahlee wrote: post #64
fastball wrote: post #37

Earlier quoted context omitted.

So not a solution for content likely to be censored or adult content. Seems like BAT is still the way to go.

The Web Monetization API standard Coil is based on does not reveal knowledge of what content is being paid for.

Sure, but the hard part of "getting paid on the internet for content" was never really "there isn't an open standard for payments!" – it was that established payment providers didn't generally want to enable transactions for certain types of content or to certain actors and/or charged prohibitive fees for the privilege of performing transactions at all.
Post reply on HN