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

51–60 of 66 posts

Re: Client-side content encryption

#51

Post by detaro »

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

As far as I know you are wrong, Google in the past did insist sites shouldn't serve paywalls to users coming via Google when they gave the full page content to Google. Which made the "google the article title" workaround for paywalls work.

(Also, this was my first comment in this thread)

Re: Client-side content encryption

#52

Post by prophesi »

This would actually be pretty cool if it was made into an open protocol. Let there be a well-known ID for encrypted paywall content, with children divs that specify which search engine's public key it was encrypted with. Search engine bots would then be able to decrypt the content with their private key.

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.

Re: Client-side content encryption

#53

Post by fennecfoxen »

andy_ppp wrote: post #23

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.

The World Wide Web is dead. Long live the Internet.

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

Re: Client-side content encryption

#54

Post by loup-vaillant »

atrilumen wrote: post #48

The web is Google's platform now, and they're locking it down. It's time for a new web, and a new user agent with a minimal core so it isn't impossible to implement.

Not sure how much I agree with the first statement, but I definitely agree with the second. That's not an easy problem, though.

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.

Re: Client-side content encryption

#55

Post by loup-vaillant »

fennecfoxen wrote: post #53
andy_ppp wrote: post #23

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.

The World Wide Web is dead. Long live the Internet. (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.)

I's more like the internet is dying, and the web is killing it.

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.

Re: Client-side content encryption

#57

Post by three_seagrass »

SiempreViernes wrote: post #27
three_seagrass wrote: post #9

Earlier quoted context omitted.

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.

Most sites can and do already do this without Google or AMP. You have missed that point entirely.

Re: Client-side content encryption

#58

Post by three_seagrass »

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.

Re: Client-side content encryption

#59

Post by mschuster91 »

loup-vaillant wrote: post #55
fennecfoxen wrote: post #53

Earlier quoted context omitted.

The World Wide Web is dead. Long live the Internet. (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.)

I's more like the internet is dying, and the web is killing it. 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.

> Fewer still allow any incoming connections.

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.

Re: Client-side content encryption

#60

Post by joshuamorton »

detaro wrote: post #51
xnyan wrote: post #49

Earlier quoted context omitted.

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

As far as I know you are wrong, Google in the past did insist sites shouldn't serve paywalls to users coming via Google when they gave the full page content to Google. Which made the "google the article title" workaround for paywalls work. (Also, this was my first comment in this thread)

Yes and no. It looks like since 2009, there was a max to the "FCF" policy, and it was entirely dropped in 2017:

https://searchengineland.com/google-first-click-free-replace...

Post reply on HN