this post was submitted on 03 Nov 2023
384 points (100.0% liked)
Technology
37717 readers
520 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You're completely wrong.
This means that they will implement it, and then it's only a tiny change to make it available everywhere if they decide to do so later.
The option alone also now also allows people to build stuff that will only work in those WebViews, rejecting to work without the integrity check, which is already a huge loss.
Can you give a concrete example how this would be a huge issue? A webview is part of an app, which is already a closed system. If a developer wants to, they can already build their app using native UI with integrity checks. Now they can do the same when using webviews. It really has none of the implications it would have for browsers.
He means this builds all the backend and proof of concepts necessary to force it on every other environment, and websites will be prepared for the switch, giving the public that much less time to react when they push it to desktop again
It’s basically “OK, we can’t stop the pushback, so we’ll tell the public it will only work on android web view, but all teams keep working full steam, we’ll wait to merge into the bigger systems until all this dies down, and we won’t have lost any dev time!”
That's what he wrote in his second paragraph and it's a fair point. In his third paragraph (the one I quoted) he claims that just having that functionality in webviews is already a "huge loss" though and I was curious what kind of scenario he was thinking of.
You don’t think having to go through all this to stop it again next time, but it’s even harder because it can now be implemented orders of magnitude faster than before, counts as a “huge loss”?