zlacker

[parent] [thread] 17 comments
1. devsda+(OP)[view] [source] 2023-07-26 14:21:51
There are many arguments against this but not many brought the implications for search engines.

If websites implement this, it will effectively make building a web search engine impossible for new entrants. The current players can whitelist/attest their own clients while categorizing every other scraping clients as bots.

If not for other reasons, I can't see how Google a search company can be allowed to push something that can kill competition using its market dominance in other areas like browsers.

replies(5): >>justco+Q6 >>dontre+L8 >>bileka+Ht >>ivanst+XC >>derefr+Is1
2. justco+Q6[view] [source] 2023-07-26 14:49:08
>>devsda+(OP)
> If not for other reasons, I can't see how Google a search company can be allowed to push something that can kill competition using its market dominance in other areas like browsers.

Because antitrust has been dead for a while. Chrome is a tool to drive people to Google and Google ads and nothing more.

I will say, I did appreciate Microsoft having a browser engine with IE and Edge, even if the former was notoriously a pain, it gave competition in the space. Unfortunately, that's not the case anymore and everything is either Chrome (Blink), Firefox (Gecko), or Safari (WebKit). And it's pretty clear what Chrome has done once that have amassed a dominant market share.

I'm sure there are Googlers who think they're legitimately making the web a safer place, but I think the real reason is pretty clear if you take a birds eye view.

replies(1): >>retrac+8u
3. dontre+L8[view] [source] 2023-07-26 14:56:42
>>devsda+(OP)
Is it possible for them to implement this API in such a way that it will fail 5% of the time or so, making it impossible for websites to deny individuals based on failing attestation?

https://github.com/RupertBenWiser/Web-Environment-Integrity/...

replies(6): >>FireBe+Da >>lxgr+1h >>smarx0+bj >>devsda+Qn >>JohnFe+Ip >>acrisp+F31
◧◩
4. FireBe+Da[view] [source] [discussion] 2023-07-26 15:03:09
>>dontre+L8
... until Google decides to dial that down to zero for "experience", or Hulu / Netflix makes you disable/whitelist/whatever to access their site.
replies(1): >>dontre+Ac
◧◩◪
5. dontre+Ac[view] [source] [discussion] 2023-07-26 15:10:10
>>FireBe+Da
But as mentioned above, isn't doing so against Google's own self interest? It seems like the project is explicitly stating their goal isn't to allow for websites to do this, and they are implementing it in a manner consistent with that.

One thing about your comment above: Hulu can't start implementing attestation until Google turns the knob to 0 because they can't start randomly dropping 5% of Chrome users. So in your comment above it should be "and" not "or". If I understand correctly Hulu cannot act unilaterally with the currently planned implementation of this.

If let's say they did turn the knob for Chrome, wouldn't it take a while for websites to start implementing this? For me not knowing as much about this it feels like this is a step in an ambiguous direction which could be good or bad still. But since it's Google everyone is thinking ahead in the causal chain. Can you help me understand why this is such a big and clearly bad step against the open web? Thank you!

replies(2): >>WorldM+9J >>alex77+e93
◧◩
6. lxgr+1h[view] [source] [discussion] 2023-07-26 15:22:53
>>dontre+L8
Why would they?
◧◩
7. smarx0+bj[view] [source] [discussion] 2023-07-26 15:29:48
>>dontre+L8
Have you seen bank "login redirects" when the system redirects you for ca. 5-10 times before actually letting you in? This proposal could be defeated in the same way: after successful authn, the user is redirected to the page '/wei_chk_1', then '/wei_chk_2' and so on until '/wei_chk_$n', e.g. 10 or WEI check success. If the WEI Javascript check succeeded on at least one page, you are logged in. Otherwise, get lost.
◧◩
8. devsda+Qn[view] [source] [discussion] 2023-07-26 15:45:43
>>dontre+L8
I cannot trust a known thief and let them into my house based on their promise not to steal.

I have no way of knowing if they are honest or not and even if they are there's no guarantee that they won't change their mind later.I cannot take the risk and be on guard forever.

I would much prefer not to allow them into the house in the first place.

Google should not have brought this proposal but they did.So, I will not place my trust in Google doing the right thing irrespective of their claims and promises.

◧◩
9. JohnFe+Ip[view] [source] [discussion] 2023-07-26 15:52:36
>>dontre+L8
I don't see how that fixes the problem.
10. bileka+Ht[view] [source] 2023-07-26 16:05:42
>>devsda+(OP)
> The current players can whitelist/attest their own clients while categorizing every other scraping clients as bots.

I hadn't really considered this. In a roundabout way, is there a process for this to be rejected on grounds of "fair use" limitations?

◧◩
11. retrac+8u[view] [source] [discussion] 2023-07-26 16:07:09
>>justco+Q6
Unfortunately it seems that nearly all software platforms with a dominant market share, end up degenerating to serve only one purpose: to shove advertisements and subscriptions onto you.

My mother's new Windows 11 laptop's out-of-the-box configuration had me clicking through half a dozen things attempting to manipulate me or her into spending more money. There are (I can only assume paid-placement) news and adfotainment in the start menu! Repeat pop-up reminders from Lenovo to subscribe to their protection package. Emotionally-manipulative reminders to subscribe to virus protection services. To Microsoft Office. Etc. etc.

It's been the same thing in the mobile market, where the move to "apps" means you are running their software on your device all the time, so they can optimally surveil you, and target the advertisements and behaviourally-modifying nudges. Quite a few messaging services now actively mess with delivery of notifications, spacing them out, delaying them, according to research that shows what maximizes engagement.

I saw the trend 20 years ago and switched to free software around that time -- I liked Linux anyway, but it was partly on principle. Still, the new laptop was eye-opening. The degree of intrusion, the degree to which even desktop computers have turned into user-hostile advertising terminals serving the purposes of their manufacturer, rather than a computer for the user to accomplish their work, is quite shocking.

Everything networked is becoming like that - twisting the user's hardware, turning it into nothing more than a terminal, an extension of the corporation, serving their interests at all times. Even smart TVs now have ads built-in to their menus and such.

replies(1): >>mrguyo+321
12. ivanst+XC[view] [source] 2023-07-26 16:40:23
>>devsda+(OP)
How would this work against scrapers that are based on driven anpproved browser instances, eg. something like Selenium?
replies(1): >>therei+te1
◧◩◪◨
13. WorldM+9J[view] [source] [discussion] 2023-07-26 17:02:44
>>dontre+Ac
I think Hulu is a great example.

Hulu has DRM issues in Firefox and their DRM just fails with unknown errors on about ~15% of content they host (anecdotally, of course, I have no specific data). There's no way for me to tell if a specific episode of a show will fail or not, some succeed, others don't. I at least find no pattern for this. From this perspective, they are essentially randomly breaking 100% of Firefox users some seemingly random percentage of the time.

They have "good" business reasons to require this DRM and whatever this random broken user percentage is, I'm sure it meets their bottom-line criteria as a business.

"95%" uptime for Chrome users is only "one-9", but it's still got that one 9. That's an acceptable SLA to many businesses. A business might easily decide attestation is worth that "uptime risk" because it sells more ads or makes the DRM vendors happier (and thus the content owners are happier) or any other number of "good" business reasons.

◧◩◪
14. mrguyo+321[view] [source] [discussion] 2023-07-26 18:05:56
>>retrac+8u
>to shove advertisements and subscriptions onto you.

There is no other end state in capitalism. If you want tools and products that serve you instead of an owner, you must do it outside capitalism like with truly open source stuff.

◧◩
15. acrisp+F31[view] [source] [discussion] 2023-07-26 18:12:11
>>dontre+L8
From the explainer:

> However, a holdback also has significant drawbacks. In our use cases and capabilities survey, we have identified a number of critical use cases for deterministic platform integrity attestation. These use cases currently rely on client fingerprinting. A deterministic but limited-entropy attestation would obviate the need for invasive fingerprinting here, and has the potential to usher in more privacy-positive practices in the long-term.

I think any holdback will eventually go away because of the "critical use cases for deterministic platform integrity attestation"

◧◩
16. therei+te1[view] [source] [discussion] 2023-07-26 18:52:02
>>ivanst+XC
The browser instance knows it is being driven by an automation agent. If you so wanted, you can actually comment out the code that does that in the browser's code but since this new setup will enable the page to check if you compiled your own browser, they'll be able to incorporate the "isUnderAutomation" flag under the attestation data and that's sealed because you can't build your own browser and have it attest.
17. derefr+Is1[view] [source] 2023-07-26 19:48:48
>>devsda+(OP)
> The current players can whitelist/attest their own clients while categorizing every other scraping clients as bots.

Can't they already do this by having scrapers send plain-old client certificates? Or even just a request header that contains an HMAC of the URL with a shared secret?

Actually, taking a step further back: why does anyone need to scrape their own properties? They can make up an arbitrary backchannel to access that data — just like the one Google uses to populate YouTube results into SERPs. No need to provide a usefully-scrapeable website at all.

◧◩◪◨
18. alex77+e93[view] [source] [discussion] 2023-07-27 07:49:50
>>dontre+Ac
> But as mentioned above, isn't doing so against Google's own self interest?

I don't see how it is against their interest, it would cement Google into power in a way that is very difficult to undo barring government intervention (which I doubt is going to happen).

> It seems like the project is explicitly stating their goal isn't to allow for websites to do this, and they are implementing it in a manner consistent with that.

If you drop a frog in a pot of boiling water, it will of course frantically try to clamber out. But if you place it gently in a pot of tepid water and turn the heat on low, it will float there quite placidly. As the water gradually heats up, the frog will sink into a tranquil stupor, exactly like one of us in a hot bath, and before long, with a smile on its face, it will unresistingly allow itself to be boiled to death.

> If I understand correctly Hulu cannot act unilaterally with the currently planned implementation of this.

Hulu will keep their attestation implementation ready to turn on at a moment's notice because it's patently obvious that the hold-back stuff will be gone when it's ready to go, and it's obvious because the currently described implementation (with the hold-back) does not really serve any real purpose.

The hold-back is only on the spec to keep people from revolting while the thing is built and tested.

[go to top]