6 ms·

It would be useful if the site listed whether these had been standardized outside of Chrome yet. It’s hard to delineate which of these are Chrome features or a

by dagmx 7mo ago

It would be useful if the site listed whether these had been standardized outside of Chrome yet. It’s hard to delineate which of these are Chrome features or actual web standards. And it’s therefore hard to blame either Safari or Firefox for not supporting them if they’re not standardized yet.

WhyNotHugo 7mo ago
This is a huge list of "features from Chromium", which aren't really standard or even a thing outside of its ecosystem (the fact that both Firefox and Safari lack them is the obvious giveaway). I'm happy that Firefox doesn't expose Bluetooth, NFC or similar stuff to websites: the browser is huge enough without needing to mediate even more access to local hardware. It's unclear how some of these would even work for other Browser. E.g.: contacts. What data source would you use? I keep my contacts as vcard files in ~/contacts, but other folks might use a remove CalDAV server, a web-based GUI, or data stored in SQL which can be read by some other native client (I think KDE does this).
- gertop 7mo ago
  Desktop Linux might not have a unified way of storing contacts but all other major operating systems do: Mac, Windows, Android, iOS. So if your blocker to accept this feature is that it's "difficult to support on desktop Linux" then all I can say is cry me a river.
- ymolodtsov 7mo ago
  Agreed. I don't want websites to even request my NFC/Bluetooth/contacts.
rafaelmn 7mo ago
It's not even features - basic stuff like input handling/focus is broken on iOS PWAs it's an obviously ignored tech.
JimDabell 7mo ago
Here’s what Mozilla has to say about Web NFC, for example: > We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written. — https://mozilla.github.io/standards-positions/#web-nfc https://mozilla.github.io/standards-positions/#web-nfc And here’s what they have to say about Web Bluetooth: > This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices. — https://mozilla.github.io/standards-positions/#web-bluetooth https://mozilla.github.io/standards-positions/#web-bluetooth The fact is that Google wrote these specifications, couldn’t convince any other rendering engine to implement them, and somehow it’s Apple’s fault the rest of the world rejected their idea. These are not web standards, they are Blink-only APIs that Google decided to build unilaterally. The web is not defined by whatever Google wants. Web standards are supposed to be arrived at through consensus, and the consensus is that these things should not be part of the web.
- leptons 7mo ago
  >The fact is that Google wrote these specifications, couldn’t convince any other rendering engine to implement them, and somehow it’s Apple’s fault the rest of the world rejected their idea. Apple is on the W3C board that gets to decide which APIs become standards. They are preventing these APIs from becoming standards. They have an interest to forbid Web Bluetooth and NFC from becoming standards, because they profit heavily from native apps on their iOS platform, where they collect a percentage of all sales made through apps, so they want to force developers to create native apps instead of web apps. I'll also point out that Opera, Edge, Samsung and others did implement the Web Bluetooth API, so you are wrong about your assertion that they "couldn't convince any other rendering engine to implement them". https://caniuse.com/web-bluetooth https://caniuse.com/web-bluetooth If you don't think Apple is abusing their power here, then you are either lacking understanding of how Apple operates, or you just love Apple a little too much.
leptons 7mo ago
>It’s hard to delineate which of these are Chrome features or actual web standards. And it’s therefore hard to blame either Safari or Firefox for not supporting them if they’re not standardized yet. Maybe you don't realize that Apple is on the W3C board that gets to decide which APIs become standards, so they can squash any API that they think could cut into their app store. Citing Firefox as some kind of evidence doesn't take into account the abusive business tactics that Apple uses to force developers to create native apps on their platform. I don't care about Firefox does, because they aren't forbidding an entire platform from using any browser engine except their own browser engine, which Apple does with Safari on iOS. So Apple controls iOS browser engines, and they also control which APIs get to become standards. This is plainly abusive. It's also part of the reason Apple is being sued by the DOJ https://www.justice.gov/archives/opa/media/1344546/dl?inline https://www.justice.gov/archives/opa/media/1344546/dl?inline
- dagmx 7mo ago
  You’ve said this above and have been corrected that Apple cannot single handedly veto proposals. Given the rest of your argument hinges on a misunderstanding of the process I’m not sure it holds much merit.
  - leptons 7mo ago
    [dead]

by dagmx 7mo ago

WhyNotHugo 7mo ago

This is a huge list of "features from Chromium", which aren't really standard or even a thing outside of its ecosystem (the fact that both Firefox and Safari lack them is the obvious giveaway). I'm happy that Firefox doesn't expose Bluetooth, NFC or similar stuff to websites: the browser is huge enough without needing to mediate even more access to local hardware. It's unclear how some of these would even work for other Browser. E.g.: contacts. What data source would you use? I keep my contacts as vcard files in ~/contacts, but other folks might use a remove CalDAV server, a web-based GUI, or data stored in SQL which can be read by some other native client (I think KDE does this).

gertop 7mo ago
Desktop Linux might not have a unified way of storing contacts but all other major operating systems do: Mac, Windows, Android, iOS. So if your blocker to accept this feature is that it's "difficult to support on desktop Linux" then all I can say is cry me a river.
ymolodtsov 7mo ago
Agreed. I don't want websites to even request my NFC/Bluetooth/contacts.

rafaelmn 7mo ago

It's not even features - basic stuff like input handling/focus is broken on iOS PWAs it's an obviously ignored tech.

JimDabell 7mo ago

Here’s what Mozilla has to say about Web NFC, for example: > We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written. — https://mozilla.github.io/standards-positions/#web-nfc https://mozilla.github.io/standards-positions/#web-nfc And here’s what they have to say about Web Bluetooth: > This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices. — https://mozilla.github.io/standards-positions/#web-bluetooth https://mozilla.github.io/standards-positions/#web-bluetooth The fact is that Google wrote these specifications, couldn’t convince any other rendering engine to implement them, and somehow it’s Apple’s fault the rest of the world rejected their idea. These are not web standards, they are Blink-only APIs that Google decided to build unilaterally. The web is not defined by whatever Google wants. Web standards are supposed to be arrived at through consensus, and the consensus is that these things should not be part of the web.

leptons 7mo ago
>The fact is that Google wrote these specifications, couldn’t convince any other rendering engine to implement them, and somehow it’s Apple’s fault the rest of the world rejected their idea. Apple is on the W3C board that gets to decide which APIs become standards. They are preventing these APIs from becoming standards. They have an interest to forbid Web Bluetooth and NFC from becoming standards, because they profit heavily from native apps on their iOS platform, where they collect a percentage of all sales made through apps, so they want to force developers to create native apps instead of web apps. I'll also point out that Opera, Edge, Samsung and others did implement the Web Bluetooth API, so you are wrong about your assertion that they "couldn't convince any other rendering engine to implement them". https://caniuse.com/web-bluetooth https://caniuse.com/web-bluetooth If you don't think Apple is abusing their power here, then you are either lacking understanding of how Apple operates, or you just love Apple a little too much.

leptons 7mo ago

>It’s hard to delineate which of these are Chrome features or actual web standards. And it’s therefore hard to blame either Safari or Firefox for not supporting them if they’re not standardized yet. Maybe you don't realize that Apple is on the W3C board that gets to decide which APIs become standards, so they can squash any API that they think could cut into their app store. Citing Firefox as some kind of evidence doesn't take into account the abusive business tactics that Apple uses to force developers to create native apps on their platform. I don't care about Firefox does, because they aren't forbidding an entire platform from using any browser engine except their own browser engine, which Apple does with Safari on iOS. So Apple controls iOS browser engines, and they also control which APIs get to become standards. This is plainly abusive. It's also part of the reason Apple is being sued by the DOJ https://www.justice.gov/archives/opa/media/1344546/dl?inline https://www.justice.gov/archives/opa/media/1344546/dl?inline

dagmx 7mo ago
You’ve said this above and have been corrected that Apple cannot single handedly veto proposals. Given the rest of your argument hinges on a misunderstanding of the process I’m not sure it holds much merit.
- leptons 7mo ago
  [dead]