Apple's WebKit team's feedback

[rniwa]

We don't support this API because:

• RAM is not a direct estimate of whether the device can run a website with good performance - Some generations of iPads, for example, has an old generation CPU with more RAM.
• Amount of RAM device has is no indicative of how much RAM a website can use - the amount of memory WebContent process can use is limited by a number of variables beyond just the amount that's physically available on a given device.
• It adds a new reliable fingerprinting surface - 100% reliability to disambiguate one device from another based on RAM size is a new fingerprinting surface we don't want to add.

[tunetheweb]

Noted.

I've opened WebKit/standards-positions#645 (with some responses to above points) to log this formally in the WebKit Standard repo so we can close this issue.

[annevk]

It seems very weird to close this issue in this manner. Shouldn't issues be closed as a result of WG discussion?

[tunetheweb]

Happy to bring it back for discussion if you think there’s further to discuss here?

I was reading above as a simple position statement rather than on engagement with suggestions on how the API could be improved so the position could be reviewed. That seems confirmed with the latest reply on that new issue I opened.

We last discussed this API at the working group on January 15th when we discussed #50 and a change on what values were reported. There was no discussion from other implementors on alternatives.

And in the rechartering discussion in TPAC we agreed this API was unlikely to progress to standardisation and because of that, it is being proposed to move back to WICG as part of our new charter.

So if this is just a statement of position, then surely it belongs more in that other repo where other WebKit standards positions are held? I see little point in keeping an issue open just for the sake of keeping it open when there is a better place to store that information.

I’m happy to link that new position issue from the README if the concern is that Apple/Webkit’s position is less obvious with the closing of the position? Or perhaps even from the spec itself (we’ve had similar discussions about the Network Information API which is also on my list to try to make some progress on).

However, if Apple/Webkit (or anyone else for that matter) wishes to help suggest improvements to this API that could potentially lead to a change in their position and eventual standardisation then I’m more than happy to re-open this issue and facilitate that discussion!

[annevk]

How is it just a statement of position? I don't even know what that means.

[tunetheweb]

I meant it's a standards position. Which is why I've moved it the place where other Webkit standards positions are logged: WebKit/standards-positions#645

[annevk]

I mean OP is clearly critique of the API. It's not just "oppose". Critique of the API can't just be dismissed but maybe if this is WICG material anyway it doesn't matter.

[tunetheweb]

I don't know what critique means and how that differs from a position? Given the whole concept of the API seems to be the issue.

Can you suggest what outcome you're looking for here? Happy to reopen if you believe there's a next action we could take to help resolve your objections to closing this issue (e.g. WG discussion).

[jyasskin]

@annevk and @rniwa, I agree that we shouldn't close issues without looking for ways to satisfy the use cases while avoiding the pitfalls you mentioned in the OP. This would go more smoothly if you could sketch or point toward some alternatives that would be closer to working for you, which the proponents could extrapolate from. For example, iOS native apps likely have some of the same problems, and Apple may have found ways to solve their problems while discouraging them from collecting a unique fingerprint. Could any of those techniques apply to the Web? Clearly the proponents can also look for ways to avoid the flaws you've identified, on their own, but progress will go faster if you also participate.

[marcoscaceres]

The risk is that this gets punted to the WICG and pseudo-standardized and shipped regardless. That’s the worst possible outcome.

That’s why it would be good to reopen to iterate on the use cases and problems the proposal is trying to address.