WICG/pending-beacon

Do we want to enforce HTTPS request?

mingyc opened this issue ยท 7 comments

One of the requirement listed in the "Privacy" section is "Beacons must be sent over HTTPS."

But would it conflict with the goal to make it easy for developers to migrate to use this API? (this wasn't a requirement for navigator.sendBeacon()).

Hi there! Chrome web platform security reviewer here, we believe that it would be best not to build new APIs that allow HTTP communications. HTTPS is well established and its deployment has never been easier.

@letitz We could update the API to only accept HTTPS endpoints, i.e. setURL('https://...');

However the API itself can still be run on a page with HTTP orign. In such case, the API cannot enforce HTTPS for relative URLs:

// In http://not-safe.com
let p = PendingGetBeacon('/target');
// p is expected to sent to http://not-safe.com/target

I am not familar with other APIs yet. Are there any examples about how to deal with this kind of issues?

I imagine the constructor could construct the full URL of the target and check that the scheme is https?

In JS (though this would likely be handled by the browser itself):

function checkUrl(url) {
  const absoluteUrl = new URL(url, window.location);
  if (absoluteUrl.protocol !== "https:") {
    throw new TypeError("scheme is not https");
  }
}

class PendingGetBeacon {
  constructor(url, ...) {
    checkUrl(url);
    ...
  }

  setUrl(url) {
    checkUrl(url);
    ...
  }
}

This behavior would have to be specified as well.

@letitz We could update the API to only accept HTTPS endpoints, i.e. setURL('https://...');

However the API itself can still be run on a page with HTTP orign. In such case, the API cannot enforce HTTPS for relative URLs:

// In http://not-safe.com
let p = PendingGetBeacon('/target');
// p is expected to sent to http://not-safe.com/target

I am not familar with other APIs yet. Are there any examples about how to deal with this kind of issues?

If you try to call navigator.geolocation.getCurrentPosition(() => {}) in a http page, it logs an error and never fires the callback. crypto.subtle, on the other hand, returns undefined on http pages. My suggestion would be that PendingGetBeacon and PendingPostBeacon are undefined on http pages, which would mean that feature detection would fall back with no further effort.

crypto.subtle, on the other hand, returns undefined on http pages.

There are a large number of APIs that are only available on https pages -- we usually do this with a SecureContext attribute in the IDL.

That's true, and we could consider restricting this API to secure contexts. However, the point of this issue is slightly different: whether requests to http URLs should be allowed or not.

Thanks for all your help. I am going to also update the explainer to only support this API in secure contexts.