What's the rationale of moving security checks outside of normative requirements?

[tobie]

My understanding of #280 is that previously normative security checks are now examples that user agents are free to implement. What's the rationale behind this? I can't find any documented reason to make these changes. This seems like it's going to hurt end user security, and make it harder for developers to build consistent experiences across user agents. And I'm not sure I understand what benefits there is to doing so. Where can I find the arguments behind these changes?

[alexshalamov]

Any time a new sensor reading for a platform sensor is obtained and if the user agent can expose sensor readings, update latest reading is invoked with the platform sensor and the sensor reading as arguments.

Check is present in normative section 6.2 Sensor

[tobie]

Each condition of the security check used to be a RFC 2119 "MUST" requirement, they're now used as examples for something the user agent "can" do (whatever that means is up to interpretation, and it's arguably non-normative):

The user agent can define the list of conditions to check if it can expose sensor readings.

The example list of conditions is presented below:

So there's a massive difference between the current state of things and what it used to be. I'm kind of surprised this actually needs to be stated.

[lknik]

Can I ask for rationale for doing so, for example justified with some analysis?

[danbri]

@alexshalamov can something be a conforming implementation of this spec if the checks shown are not routinely performed?

[tobie]

For reference, here's what the security check previously looked liked: https://cdn.rawgit.com/w3c/sensors/29065ab/index.html#security-check

It was normatively required as first step of https://cdn.rawgit.com/w3c/sensors/29065ab/index.html#update-latest-reading

[pozdnyakov]

That was an oversight, thanks for reporting! In Chromium all these checks defined in conditions are implemented. We will make them MUSTs.

[alexshalamov]

@danbri Thanks for feedback! We wanted to open possibility for UA to implement additional checks to implement required mitigation strategies. We are working on improving the definition for required checks in #288, please feel free to comment and suggest improvements.

[tobie]

I don't understand why you don't just roll these changes back instead of reworking it further. There are plenty of issues with this PR including now using normative keywords in informative sections, etc.