zlacker

[return to "So, you don't like a web platform proposal"]
1. 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?

◧◩
2. goku12+Js[view] [source] 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/...

◧◩◪
3. yoavwe+3x[view] [source] 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_...

◧◩◪◨
4. sgammo+Ek3[view] [source] 2023-07-25 22:23:54
>>yoavwe+3x
The proposal creates a mechanism by which digital rights could be enforced, so it could be used as DRM.

Arguably, any ability to deny particular user agents is discrimination. Doing that in a cryptographically verifiable way is DRM or at least a primitive which can be used to build DRM.

> This could definitely be risky for the open web

Then it should not be done.

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

Whether the proposal specifically mentions copyrights or DRM is immaterial; I don't even know why you would make this point.

> In my book this is not a blocker for being able to discuss any of this

First of all, respectfully, "your book" is not relevant; you are acting in your capacity as a chair, are you not? Second of all, yes, if something is morally abhorrent, it is not even worth discussion. You are still not understanding why people are reacting this way. Please, again, I implore you to reconsider your interpretation of these responses; people are trying to tell you that this proposal is SO dangerous, and SO bad, that it should be deleted from existence and never discussed again.

◧◩◪◨⬒
5. shadow+jC5[view] [source] 2023-07-26 15:23:27
>>sgammo+Ek3
If we delete it for existence it'll just come up again; the benefits for web developers are extremely compelling.
[go to top]