zlacker

So, you don't like a web platform proposal

submitted by KoftaB+(OP) on 2023-07-25 03:55:43 | 92 points 105 comments
[view article] [source] [go to bottom]

NOTE: showing posts with links only show all posts
13. rtpg+Jj[view] [source] 2023-07-25 06:59:18
>>KoftaB+(OP)
Since this is here and there is a point made about discussing the technical merits of [0]... can someone explain to me how the WEI stuff isn't easily "faked" by scrapers and the like?

I could see this being used in a similar way to user agents (sometimes helpful when working on bugs and fixing them on minor platforms!), but I'm really struggling to see the overall value-add here.

I get the politics aspect of it (I think...), but what's the new technical thing being added here?

[0]: https://github.com/RupertBenWiser/Web-Environment-Integrity/...

◧◩◪
29. goku12+Ko[view] [source] [discussion] 2023-07-25 07:42:23
>>charci+nk
Here's how they respond to 'constructive arguments': >>36855429 . Especially this part: https://danshumway.com/blog/chrome-autoplay/
33. Zandik+xp[view] [source] 2023-07-25 07:49:23
>>KoftaB+(OP)
I take real issue with their occams razor comment under "Don't assume a hidden agenda" [0]

> it's often safe to assume that Occam's razor is applicable and the reason it is being proposed is that the team proposing it is trying to tackle the use cases the proposal handles

Just because something is initially conceived innocently and in response to a purely technical problem does not mean it wont be co-opted by the parent company that has a track record of establishing market hegemonies and anti-competitive practices. Humans didn't split the atom because we wanted to vaporize cities, we were merely curious about the "technical" fabric of reality as a natural pursuit of science. Furthermore, just because you're tasked with working on the technical problems, doesn't mean that technical problems are the only aspects that can or should be considered. It's plain as day how this will have non technical implications, and asserting those should be ignored for any reason - but especially in this context - is frankly insulting.

In other words, this seems to be a textbook case of "they were too preoccupied with whether or not they could, they didn't stop to ask if they should."

> To be more concrete and clear, personal attacks or threats addressed at the folks working on the platform are not OK

We agree on that at least.

[0]: https://blog.yoav.ws/posts/web_platform_change_you_do_not_li...

39. yoavwe+br[view] [source] 2023-07-25 08:03:25
>>KoftaB+(OP)
Blog post author here.

A few clarifications:

* I am not a contributor to the repo, and stepped in as chair on the repo after writing this, to help the engineers contributing to it deal with clear spam & abuse cases. I wrote this post with WEI in mind, but nothing about it is specific to this proposal, and could've been applied to multiple past proposals (and probably future ones), either from Google or from other standards participants.

* Political/ecosystem arguments are technical arguments. See https://blog.yoav.ws/posts/web_platform_change_you_do_not_li...

* If you're objecting to the goals of the proposal [1], it'd serve you better to outline which goals are objectionable and why. Mozilla folks did a good job at articulating that in https://github.com/mozilla/standards-positions/issues/852#is...

A couple of things I should've included in that post and didn't:

* It's important to actually read and understand the proposal before objecting to it. For example, WEI has nothing to do with ad-blockers or DRM (in the sense that the content itself is not restricted, unlike EME). It does have real eco-system risks that the proposal would need to address before moving forward. Objecting to the latter makes sense. Objecting to the former is easy to dismiss as a misunderstanding.

* At the end of the day, in the case of Chromium, your goal is not necessarily to convince the proposal's proponents, but the API owners [2], many of whom are not Google employees.

[1] https://github.com/RupertBenWiser/Web-Environment-Integrity/... [2] https://blog.chromium.org/2019/11/intent-to-explain-demystif...

P.S. I'd love to discuss this with y'all like professional adults. Can we do that?

◧◩
48. goku12+Js[view] [source] [discussion] 2023-07-25 08:17:35
>>yoavwe+br
I don't believe in attacking individuals for what is a systemic issue.

> It's important to actually read and understand the proposal before objecting to it.

How do you assume that the people who criticize it didn't read it? I saw many arguments based on the proposal text. I myself read it thrice before making my first post.

> For example, WEI has nothing to do with ad-blockers or DRM (in the sense that the content itself is not restricted, unlike EME)

From what I can see, the webpage needs to return the token to the server before it decides to respond [1]. True that proposal doesn't say if the server should respond or not. But the mere possibility that the server can deny a response based on the token (or its absence) means that it will be used. How is this not DRM? And how is this not dangerous to the open web?

[1] https://github.com/RupertBenWiser/Web-Environment-Integrity/...

◧◩◪
62. yoavwe+3x[view] [source] [discussion] 2023-07-25 08:55:24
>>goku12+Js
> I don't believe in attacking individuals for what is a systemic issue.

I appreciate that!

> From what I can see, the webpage needs to return the token to the server before it decides to respond [1]. True that proposal doesn't say if the server should respond or not. But the mere possibility that the server can deny a response based on the token (or its absence) means that it will be used. How is this not DRM? And how is this not dangerous to the open web?

This could definitely be risky for the open web, and that's an argument to put forward [1]. In my book this is not a blocker for being able to discuss any of this. (but could be a blocker for shipping this proposal without proper mitigation)

At the same time, I perceive DRM as a way to control access and ability to copy copyrighted material. I couldn't find anything in this proposal that enabled any of that.

[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...

65. difosf+8z[view] [source] 2023-07-25 09:18:00
>>KoftaB+(OP)
For those like me unaware of the context here: https://www.theregister.com/2023/07/25/google_web_environmen...
◧◩◪◨
66. Modifi+cz[view] [source] [discussion] 2023-07-25 09:18:18
>>ikekkd+Lp
Incidentally, here's a new crowdsourced scheme for TF2 that even in prototype form has been addressing the issue far better than Valve's efforts:

I Pissed Off Every Cheater in TF2 (Data Breach Gone Wrong) | https://www.youtube.com/watch?v=LVgk5t64cRs

Creating a Third-party Client to Auto-kick Cheaters and Bots from TF2 (Part 1/3) | https://www.youtube.com/watch?v=EPsWjdkyoPo

Basically cheaters don't seem to want just a one off high like a classic troll out for havoc, they want a reputation of being better than they are for an extended ego trip. Their choice will soon be either restraining themselves to becoming very subtle, or keep having to make new accounts.

◧◩
73. nobody+pR[view] [source] [discussion] 2023-07-25 11:56:58
>>yoavwe+br
>* If you're objecting to the goals of the proposal [1], it'd serve you better to outline which goals are objectionable and why. Mozilla folks did a good job at articulating that in https://github.com/mozilla/standards-positions/issues/852#is...

Well, you asked for it, so here goes. WEI (IIUC) requires (at least the proposal claims such a thing) "attestation" of my devices in order to ensure that advertisements (and the sites they are displayed on) are actually viewed by humans and not bots engaged in gaming the ad system and 3rd party content creation.

The proposal would require me to give (without choice or recompense) data, CPU cycles, network bandwidth and, most importantly some portion of my privacy to accomplish such "attestation."

Without allowing such intrusions on my private property (i.e., my devices), the proposal as it stands, could (and with wide adoption, would) block me from accessing sites of my choosing. And that's antithetical to the idea of the open internet.

I provide a bit more detail in this comment[0] in a different discussion[1] of this proposal, wherein I detail that these are issues between advertisers and Google that have absolutely nothing to do with me.

Why should I be required to donate CPU cycles, storage, bandwidth and give up some privacy so a multi-hundred billion dollar corporation can better serve its customers (again, neither of whom I have any sort of business relationship with) and improve its financial performance?

Perhaps you could enlighten me on what benefit WEI has for anyone other than Google or its customers (that'd be advertisers)?

[0] >>36860125

[1] >>36857032

◧◩◪◨⬒⬓
85. charci+B42[view] [source] [discussion] 2023-07-25 17:08:40
>>lozeng+Pp
https://github.com/RupertBenWiser/Web-Environment-Integrity/...
◧◩◪◨⬒
98. sgammo+Tj3[view] [source] [discussion] 2023-07-25 22:19:31
>>sgammo+bJ2
https://en.wikisource.org/wiki/The_Coming_War_on_General_Com...
103. tentac+l95[view] [source] 2023-07-26 13:37:21
>>KoftaB+(OP)
> It also doesn't mean that the proposal is "done" and the proposal authors won't appreciate constructive suggestions for improvement. Different proposals may be in different stages of their development, and early stage proposals are often extremely malleable.

It's important to note that this is, as of now, much less "malleable" due to it being implemented in Chromium[0]. Personally, it looks like it's just been implemented and then someone has thrown together a standard later.

The same person behind the specification has also published a testing suite[1] for the API, too. Pretty damning, if you ask me.

[0]: https://source.chromium.org/search?q=getEnvironmentIntegrity... [1]: https://rupertbenwiser.github.io/wei-wpt/

[go to top]