yoavweiss_

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

Do you know why this proposal is over a public repo which is not a part of any official open web group discussion?

A typical workflow for standard proposals is: personal repo => incubation venue => official working group

This proposal is so early stage that it hasn't passed the "personal repo" phase just yet.

Why would anyone with legitimate concerns for unforseen consequences which would occur if the proposal or any descendants of it to turn to a standard would want to be constructive about it? Particularly considering the concern if they want to stop it on the tracks?

"being constructive" doesn't mean being supportive. If the goal is objectionable and you want the work to stop, articulating why it's objectionable is your best bet at getting what you want.

Why would you not like to get the legal related feedback, don't the legalities dictate technical constraints? Or do you think this would go on with or without being in the legal?

Actual legal concerns obviously get addressed (and doing that goes through legal counsels). But throwing "legal words" into feedback significantly increases the friction of answering it, without increasing its weight or validity. That can decrease the chances of it getting addressed.

Nobody is missing this; you're defending this work. You can't both defend the work itself and place yourself outside of the process as a "chair."

I'm not defending the work. I'm defending the venue, to enable standard proposal work to happen in public (and get feedback from the community).

But it is DRM because it can be used, in effect, like DRM. You are missing the point that most of the community sees this as DRM-like technology, with all of its warts, whether you agree with that conclusion or not.

OK, maybe I'm missing something then. Can you explain to me in what ways this is DRM?

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?

The spec has been split into smaller pieces. The first one that made the most progress is https://wicg.github.io/feature-policy/

The canonical link in that aspect is http://wiki.whatwg.org/wiki/Why_not_conneg

There are various people in various vendors (Mostly Mozilla and Apple) that oppose conneg based solutions. I didn't mean to be vague, just didn't think it's very interesting :)

It's important to note that the opposition is not unanimous, and things may change in the future.

I looked into that in http://blog.yoav.ws/2012/05/Responsive-image-format

But image formats are hard, since they require an eco system, investment from large cos, etc. Maybe in a few years...

The browser can do whatever it wants (read: whatever's best for users) in this case. Current Blink (Chrome/Opera) code wouldn't download the higher res image for 'x' descriptors, but that may change in future versions, perhaps tied to user preferences,network info and other possible conditions.