Add secure context criteria to pointerrawupdate and getCoalescedEvents

[NavidZ]

Add secure context criteria to pointerrawupdate event
and getCoalescedEvents APIs to reduce its exposure
to possible attacks such as injecting scripts to http traffic.
closes #277

---

Preview | Diff

[NavidZ]

@domenic for the pointerrawupdate which is an event type of PointerEvent and is the only pointer event that is going to be restricted to a secure context is this enough to indicate its SecureContext restrictions? In other examples I saw in other specs all the events of a specific interface had this restriction and hence they added the [SecureContext] to the interface itself. But that doesn't work here.

[domenic]

You also need to update whatever normative text fires a pointerrawupdate event to have it not do so when an appropiate global is not a secure context. Just hiding the event handler attribute wouldn't stop that spec text from executing and causing addEventListener("pointerrawupdate", callback) to trigger.

[domenic]

It appears the section to update is https://w3c.github.io/pointerevents/#the-pointerrawupdate-event

[NavidZ]

Does this look good?

[domenic]

Seems reasonable, although the phrasing is a bit awkward. But within the existing structure of that section it should work.

[smaug----]

I couldn't find tests for this, at least for the pointerrawupdate. And I'm not sure https://wpt.fyi/results/pointerevents/idlharness.window.html?label=master&label=experimental&aligned&view=subtest&q=idlharness gets run in https contexts. The link in the page leads to http site.

Implementations seem to expose getCoalescedEvents on non-secure contexts too
https://searchfox.org/mozilla-central/rev/05f486c76f84830041e51b7c68e3e697dc768454/dom/webidl/PointerEvent.webidl#38
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/pointer_event.idl;l=1?q=pointer_event.idl&sq=

[smaug----]

Finally adding a test for this. Need to move quite a few tests to be loaded from .https and then have some tests for non-https to ensure the features aren't exposed.

[smaug----]

web-platform-tests/wpt#42527

[mustaqahmed]

Thanks @smaug---- for fixing a bunch of WPTs around this.

This calls for new WPTs to be included in the Interop 2024 proposal (web-platform-tests/interop#472). Please consider voting for some of the WPTs you updated here (and maybe other WPTs too).

[szmarczak]

Add secure context criteria to pointerrawupdate event and getCoalescedEvents APIs to reduce its exposure to possible attacks.

@NavidZ This does not stop any attacks.

Both of getCoaelscedEvents and pointerrawupdate APIs expose some high frequency input and might expose some fingerprinting possibilities to the app.

This just limits fingerprinting to https websites. Considering that you can get free TLS certificates today this limitation is pointless and just makes [game] development a little bit harder (because you just can't open a local .html anymore, need https). There are other endless possibilities, such as localhost tracking on mobile devices.

I hate to see these artificial limitations. Another example is limiting hash functions to secure contexts only. In those scenarios people just import a third party library, which is error prone and only adds technical debt because of this poor decision.

A better fix would be a permission prompt-based system (see: screen capture on Wayland), regardless if the website uses encryption or not (and we all know that encryption != authenticity, right? RIGHT?).

[NavidZ]

@szmarczak this PR was merged a while ago and I do encourage you to file a new issue as that might give you more traction. from the current editors and maintainers of the repo as I have been away from this standard for quite some time.

To your original question, I think the PR description should have been more clear in the hindsight. I updated a bit for posterity. I totally agree that these sort of changes makes it a bit harder (but not impossible) for developers to setup localhost testing.

The goal of these https restricted APIs is not to protect the user from the website owner. That scenario is indeed remedied by permission controlled APIs as you suggested at the cost of users needing to take an explicit action and there are quite a lot of them as well and they are used for generally more sensitive stuff. The goal here was to protect against man in the middle attacks and to disallow a script that doesn't belong to the host a user is visiting to get this information like one that can get injected into the http traffic. Note that even permission based APIs if enabled on a non-TLS domain run the risk of getting abused by mitm attackers. I don't have a list of all of those permissions and whether they are even allowed for non-TLS domains but that is beyond the scope of your question anyways. Either way, this was just a bit of background on this change (and potentially similar changes). Again feel free to file new issues and provide your input to the current spec editors and hopefully this along with other standards improve overtime.

[szmarczak]

That scenario is indeed remedied by permission controlled APIs as you suggested at the cost of users needing to take an explicit action and there are quite a lot of them as well and they are used for generally more sensitive stuff

No, it does not remedy anything. It just disables autoplay (irritating behavior) & auto full screen (full screen scam popups). Which is a good thing for non-technical people.

The goal here was to protect against man in the middle attacks

There is no correlation between raw mouse events and man in the middle. If you have proof, even theoretical, I'd love to read it. Like I said earlier, even though you can't use browser-implemented hash functions, you can import a third party library at the cost of additional technical debt.

disallow a script that doesn't belong to the host a user

Disabling raw mouse events does not achieve that. If someone wants to disallow MITM, then they need to use encryption. However, one need not do MITM to perform an attack. They can use a domain that is very similar to the victim. So using HTTPS does not prevent such attacks, any limitations on unencrypted HTTP are pointless.