71–80 of 101 posts
Earlier quoted context omitted.
Because there's typically at least a minimum of safety checks before an app can go into the app store, whereas a website can do whatever it wants (and can).
Almost all of these APIs still require a user to approve their use in the browser for a given origin.
Earlier quoted context omitted.
You can check why Mozilla and Apple have opted to not support this. https://github.com/mozilla/standards-positions/issues/154 https://github.com/WebKit/standards-positions/issues/28 Neither Mozilla or Webkit are satisfied that the proposal is safe by default, and contains footguns for the user that can be pretty destructive.
And what are they suggesting to improve the proposal? Apple, which makes $20B a year with Safari, surely has enough resources to make a counter-proposal?
> Colleagues and I have discussed this and don't see a way to grant write access to the end user's local file system in a way that safeguards the end user's interests.
Earlier quoted context omitted.
Me too. Device orientation, USB, Bluetooth, vibration, they don't belong in a web app.
Why would they belong in a platform-specific app but not in a standard-based web app? Because Apple can't get 30% out of it?
As for the 30%, How long do you think it would be before Chrome decides to monetize their web apps? The Manifest v3 story was a hint, maybe not everyone got the memo.
Earlier quoted context omitted.
And what are they suggesting to improve the proposal? Apple, which makes $20B a year with Safari, surely has enough resources to make a counter-proposal?
The counter-proposal is: don't do it. This comment by the Apple guy sums it up well IMHO: > Colleagues and I have discussed this and don't see a way to grant write access to the end user's local file system in a way that safeguards the end user's interests.
Earlier quoted context omitted.
You can check why Mozilla and Apple have opted to not support this. https://github.com/mozilla/standards-positions/issues/154 https://github.com/WebKit/standards-positions/issues/28 Neither Mozilla or Webkit are satisfied that the proposal is safe by default, and contains footguns for the user that can be pretty destructive.
I think there is a pretty secure approach of doing it. 1) When loading a file, nothing needs to be different from the already available upload functionality. The user picks the file to load. 2) When saving a new file, nothing needs to be different from the already available download functionality. The user picks the name and the place to save it. Only after 1 or 2 have already happened can the page request to update…
https://github.com/mozilla/standards-positions/issues/154#is...
Earlier quoted context omitted.
The counter-proposal is: don't do it. This comment by the Apple guy sums it up well IMHO: > Colleagues and I have discussed this and don't see a way to grant write access to the end user's local file system in a way that safeguards the end user's interests.
So they can make it to work for platform-specific apps that they tax 30%, but can't make it to work for interoperable web apps which they can't tax. How convenient.
https://developer.mozilla.org/en-US/docs/Web/API/File_System...
https://webkit.org/blog/12257/the-file-system-access-api-wit...
It's able to support this because the 'file system' is scoped specifically to that origin, and doesn't allow access to any aribtary location on the file sytem, just like iOS.
Yes, Apple has dragged its feet on standards but things that Chrome just decided on by itself are not standards.
A number of the partially implemented (on iOS) things (like clipboard or volume) have legitimate privacy concerns or UX concerns. I don’t want a website to read my clipboard, I don’t want a website to change my volume.
There are some more legitimate looking things but a number of those are not part of the spec according to this very website.
I’ve said for years that Chrome is closer to IE in writing their own standards and Safari is closer to IE in conforming to the standards. But blanket “Safari is the new IE” statements are just silly and miss the forest for the trees.
Earlier quoted context omitted.
I don’t think I’ve ever seen a missing person on a milk carton in the US either. It is only something I’ve seen in TV and movies, and I’m in my 40s. My assumption is that this was a thing from the 1950s, but someone who grew up during that era would have to speak to it. I suppose it’s also possible it was a regional thing and I wasn’t in a region that did it.
You sent me down a rabbit hole. Wikipedia got us covered: https://en.wikipedia.org/wiki/Missing-children_milk_carton
It’s amazing something so short-lived had such an impact.
Earlier quoted context omitted.
All the dangerous ones come with comprehensive permissions prompts, and browsers can offer options for don't ask again/never ask etc, so if you're not interested there's still little downside to those being available for those who are. Personally, I've found a bunch of these super useful, as user and a developer. Being able to use tools like https://www.espruino.com/ide/ to play with hardware straight from the web is…
I would guess that most regular users are very quick to click “Allow” on a dialog box. I like how macOS handles unidentified apps where you have to navigate manually to the security settings to allow an unidentified app.
You don’t need to do that, you can just right-click the app and choose “Open”.
Earlier quoted context omitted.
That's more or less how HTML has always been. Before Chrome, it was IE just adding stuff. Before IE, it was Netscape just adding stuff. JavaScript itself is just a browser adding stuff. Like it or not, W3C standards have always been reactive to what browsers are already doing. And what's really remarkable about this list is that quite a few are supported on Safari on Mac, just not on iOS. Like autofocus. It's just a…
That doesn’t mean that we should just adopt any nonsense that Google comes up with. Also autofocus on page load is a terrible idea on iOS as it automatically brings up the keyboard. No one wants to switch between web pages and suddenly have to wait for the keyboard to appear each time on page load.