Follow

refuses to add support for 16 web APIs for privacy concerns. I look at the list and I wonder - what is wrong with you web people? What are you doing? This is not the web I want. This is Orwellian and out of control. zdnet.com/article/apple-declin

The browser is becoming a backdoor, almost malware with all these possibilities. This absolutely doesn’t sit right with me. No single program should have such power over my device.

Show thread

I mean, honestly, who needs a network level firewall when we can just shoehorn every evil thing in a https tunnel? And give the browser full control? Isn’t that the very definition of a backdoor?

Show thread

@jwildeboer These APIs have been added to make the web as a platform as close to native apps as possible.

In the browser the user actually has to permit each of them manually and has greater control as in native apps, which just get permissions for these kind of device APIs out of the box most of the time. IMHO it is handled more transparently to the user on the web than on native. But I agree that most of them are not required for websites, but only for webapps.

@jwildeboer Other way round: We used to have stuff such as CORBA or RMI for client/server or server/server communication. Eventually, most of these communication channels at the very least failed whenever "external networks" and firewalls came into play. And now people fall back to HTTP because apparently it's the only thing that works somewhat reliable for this kind of stuff across networks and systems. 😟

@z428 Yes. And that’s called „circumvention“ when I’m friendly. „Backdoor“ when I’m realistic.

@jwildeboer Yes. From one point of view. From another point of view: I remember having weeks of discussion (in the late 1990s) trying to convince a customer site admin to make sure the Java applet based application we used to deploy back then is able to talk to the collaboration server in our datacenter. And that's not just us. At some point people gave up on these discussions and fell back to something that "just works" - HTTP(S) with all of its drawbacks. 😐

@jwildeboer (No, I don't like that approach at all. But I can understand and, to some point, relate to it. I wish things would have been better even back then.)

@z428 @jwildeboer you wanted to bridge networks and wondered why the sysadmin on the other end didn't think it was awesome?
I see...

@qrsbrwn Well, actually no. We wanted to get to run an application (specialized data and communication exchange platform for civil engineering projects) the "customer" (that sysadmins organization) has paid us to provide because its users needed it. Unfortunately, the sysadmin on that organizations site saw his main job not in supporting us to get this to work in a meaningful and secure way but essentially in keeping "his" firewall rules clean...

@jwildeboer

@qrsbrwn Nowadays (as mentioned in this thread) "we" as well as most of our competitors have given up on "rich client" technologies (that would require to deploy and support applications on local infrastructure) and use web/HTTP based approaches instead. Deploying business applications that need local installations and updates across various customers has always been close to impossible to do right, and I am convinced this is one big reason for current browser predominance. 😐

@jwildeboer

@z428
While not in the room when it happened I know from experience that many enterprise applications wants plenty of ports open in firewalls without anyone being able to tell what data will flow that way and how the traffic will look.
Generally vendors of proprietary software see no problem in making Swiss cheese out of their clients firewalls in order to do things like count number of installations.
This often goes into direct conflict with company policy.

The real problem is always the lack of communication. Applications are delivered in a way that makes ops want to kill themselves but no one has the time to tell businesses how to package software in a way that doesn't kill ops.

@jwildeboer

@qrsbrwn Yes, of course. Having been of the sysadmin side of the fence for quite a while, too, I know that rather well, and yet disputes about that were just ... weird, starting with the fact that the application actually was *cough* Java (which seems just "not the best friend" to developers but a sworn enemy to some sysadmins). So, overally, in this case we wasted hours and ours lost in between this organizations "management" team (wanting us to *finally* deliver ...

@jwildeboer

@z428
Java has a bad reputation because it has, from an ops point if view, been very very very very very very bad.
Garbage collection has only recently started working. The promise "write once, run anywhere" has tricked many executives into thinking that they don't need to maintain applications.
Java applications often has had problems coexisting with eachother leading to less application density.
Certificate handling is just balls.

Many things has improved but many argue that it is too little too late. I'm just glad I'm not deploying Java apps for a living. Oh... I forgot about the fucking JVM, let's never talk about the jvm ever.
:)


@jwildeboer

@qrsbrwn From where I stand (sysadmin and dev), you missed a few "very"s in your list. And in some ways it still is. Garbage collection was broken most of the time. Desktop integration still is broken. Certificate management is something I don't want to talk about. Deployment and packaging sucks. And *yet*: Is it, as a cross-platform approach, better or worse than "the browser" or "electron"...? 😉

@jwildeboer

@qrsbrwn Unfortunately, every other approach (including native applications) is considerably more complex. And "native" applications includes other ugliness - such as having to go through Apples review process (for deploying to iOS). 😐

@jwildeboer

@z428
Yeah... I don't know anything about apps. I work strictly server side :)

@jwildeboer

@qrsbrwn ... which is my preferred environment as well, and *incredibly* much more easy than all the desktop/client stuff. 😉

@jwildeboer

@z428
Well, most of the desktop stuff is so very very dumb :)

@jwildeboer

@qrsbrwn ... the solution they contracted us for) and the admin (who repeatedly refused to help getting this set up right because at this time only mail, FTP and HTTP protocols were allowed to make it out of the network while we needed Java RMI) per corporate policy. At some point, in this dispute, we gave in and replaced RMI remoting with Hessian (binary protocol tunneled through HTTP) so the sysadmin was "happy" to have our application communicate in accordance to its policy. 😟

@jwildeboer

@z428
So basically the sysadmin was doing what policy mandated. It didn't suit your product and because of that the sysadmin was at fault?
The sysadmin might have been a complete asshole (many of us are) but it seems what you had problems with was client companys policies.

I do this too, I often blame devs when I really should be blaming management ;)

@jwildeboer

@qrsbrwn No, the sysadmin wasn't at fault here for enforcing the corporate policy. That's his job. And I'm not really arguing against this. Yet, I would have expected some communication, like, "dear management, dear vendor, this application doesn't comply with our policy, please let's figure out what to do" - which didn't happen. Essentially he was down a "I'm just doing my job and my job is enforcing the current policy" route. Which is valid and I don't even think ...

@jwildeboer

@qrsbrwn ... it's bad. But starting point of this discussion was wondering why so many people (developers) moved to HTTP and browser based solutions - and this is one core reason in my opinion: Using a technology that is "around and available" on most systems anywhere, an application runtime you can use and deploy stuff without requiring too much time and effort in coordinating things with local sysadmins. *No*, this is not good. I don't applaud it. But I can understand it. 😐

@jwildeboer

@z428
Well, many sysadmins can't even people at all :D
Of course it could have been handled better mainly via better communication.


@jwildeboer

@jwildeboer I suppose it will require appropriate rights, so you can decide not to grant them.

@sesivany so 40+ „allow access to API X“ popups every time I visit a site?

@jwildeboer That's bad UX, I agree. But application development is moving to web no matter if we like it or not, making web apps as powerful as their native counterparts is a natural motivation, so browsers/web enginers will eventually have to find a way to deal with this.

@jwildeboer My interest: Can I bend IoT hype to combat this JS hype?

@jwildeboer That's not a problem with "web people". That's the browser more and more turning into what "we" have failed to build in a better way before: A rich-client, cross-platform development kit for virtually every kind of application you could possibly imagine. 😐

@jwildeboer It surely is the web I want. I want to build web apps and use them on all my devices.

@jwildeboer I think the "bad" reason the browser does this is based on the thread's comments regarding firewalls; but what I've come to consider the"good"reason for it is that the browser is (& @this point, I guess I mean Firefox, specifically) the only Open runtime we have left: if it couldn't do all these things, then every innovation, no matter its scale, would be beholden to Apple, Google, or Microsoft. I'm not sure good outweighs bad: but I think it's a vital trade-off to keep in mind

@jwildeboer Wow I'd never heard of Web USB before. That sounds crazy!

Sign in to participate in the conversation
social.wildeboer.net

Mastodon instance for people with Wildeboer as their last name