zlacker

[parent] [thread] 3 comments
1. FireBe+(OP)[view] [source] 2023-07-26 15:03:09
... 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+X1
2. dontre+X1[view] [source] 2023-07-26 15:10:10
>>FireBe+(OP)
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+wy >>alex77+BY2
◧◩
3. WorldM+wy[view] [source] [discussion] 2023-07-26 17:02:44
>>dontre+X1
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.

◧◩
4. alex77+BY2[view] [source] [discussion] 2023-07-27 07:49:50
>>dontre+X1
> 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]