"If you're seeing this message, that means JavaScript has been disabled on your browser.

Please enable JavaScript to make this website work."

I'm so sick of websites websites refusing to even display text and images if I don't agree to run their proprietary Javascript on my computer. Isn't it time that browsers started treating requests to run Javascript like requests to use the mic or camera, and asked the user before allowing them? Ideally with crowdsourced info about what the scripts are, and what they do? In other words, make something like #NoScript a standard part of browsers.

Show thread

@strypey Be careful what you ask for: that would kill the peer web before it started. JavaScript on the client isn’t the enemy. Business logic on the server is the enemy.

@aral @strypey I don't begrudge you for using the expedient tools of today, but I must request stand in the way of developments that NEED to happen to ensure all the software we run is libre. So we can do better than the whack-a-mole efforts like your Better (which I really appreciate, btw, thank you!).

Apple and Microsoft already learnt their lesson about auto-executing CD software, but that vulnerability only moved to The Web.

@aral @strypey I agree strongly with you that logic must be clientside.

I disagree that The Web is a good tool for that. It has it's place, but we really need to pushing for libre native apps following open standards.

And browsers should assist with that be pointing people towards the apps they need to use those standards securely. I've implemented that for Odysseus.


@alcinnz @strypey Agree. But we need untrusted relay nodes to guarantee findability and availability to match expectations of the levels possible in centralised systems if we want to build a bridge from here to there. We can shed those training wheels once there are enough nodes. But without them we won’t get adoption.

@aral @strypey I do not see how these untrusted relay nodes (which yes, we do need), but I do not see how that relates to the argument we are having. Why can't we be distributing native apps for each platform?


@alcinnz @strypey I agree. But I don’t have the resources to do so. So I’m starting with an offline browser app first and then hopefully we’ll inspire others to build native apps. But there is no one size fits all; a plurality of approaches and initiatives can only make us stronger.

@aral @strypey And as I said at the start, I don't begrudge you for doing so.

Why should there be a "client" if the logic is entirely on the client side? We can just turn to P2P networking and destroy the idea of "servers"
@strypey @alcinnz

> We can just turn to P2P networking and destroy the idea of "servers"

I like this idea politically. But after 20 years of waiting, I've yet to see a single piece of network software that can work entirely #P2P, without supernodes of any kind for bootstrapping, relay, ID mapping etc. Can you think of one? #BitTorrent needs both trackers and search sites to be useful. Even #BlockChains need "miners", which are supernodes, not pure P2P.
@buoyantair @aral @alcinnz

Having said that, I agree that supernodes don't have to be as centralized as servers. The #fediverse takes this one step, by connecting standard servers. The next step might be to disaggregate server functions, with some specializing in authentication, or media storage, or search, and so on. But we can't get rid of the concept of servers entirely without giving every device a persistent IP address (#IP6), and creating a decentralized replacement for #DNS.
@VeintePesos @buoyantair @aral @alcinnz

@buoyantair I don't know enough about the network topology of #Scuttlebutt to be sure, but from what I've learnt so far, it seems unlikely to be able to work on a large scale without a much greater use of "pubs" and other such supernodes. I don't see that as a problem (see the second post). To me, it just means that server/client and P2P are two ends of a spectrum, rather than a hard dichotomy, and that successful future network tech will involve hybrids of the two.
@alcinnz @aral @VeintePesos

@alcinnz @strypey @aral

that’s one reason i think it important to reuse bit torrent infrastructure. there are already hundreds of public trackers and methods for relaying across NAT boundaries. the protocol could use some improvements, but as long as the extensions are backwards compatible we can still leverage the network effect of mainline dht.

that said, idk how this applies to native vs web. if browser apps were light enough to run on an rpi i wouldn’t have a problem, but i know for a fact that this is not the case.

@xj9 @strypey @aral It's a concern for lightweight browsers that leads me to suggest we think about moving beyond JavaScript. That I encourage native.

Though to be clear Aral's logic for developing web apps is sound.

I come to this from feeling some responsibility to understand the code, WebKit, which forms a major part of my native app, the Odysseus web browser. And because of that I've got a strong understand of just how bloated the "web platform" has become.

@alcinnz @xj9 @strypey @aral I'm not a javascript developer but I have tried to install and maintain a lot of javascript apps. My view is that javascript has an awful development "ecosystem" and it's one of the least stable languages. nodejs apps often have hundreds (or more) dependencies, any of which can make everything fall over. Similar problems apply with python as a web development system. Maintaining nodejs apps within Freedombone is one of the hardest tasks.

For the web interface I've written recently I avoided javascript altogether and my assumed environment is a Tor browser with javascript turned off. In some regards this would have been far easier to write with javascript, but it would also be easier to introduce security problems that way.
@mcread @strypey @aral @alcinnz @bob

javascript isn't the only language you can use to make graphical apps. people use to write those in Python, C, and basically any other language you can think of. i'm working on a guide that covers building a reactive graphical stack (among other things) in Golang. the goal is to make the whole platform hackable in any language.

@xj9 @mcread @strypey @aral @bob Sidenote: some languages were designed specifically for a given platform.

You must certainly can list JavaScript in that (though wouldn't say it's a very good match), but I'm more inclined to list Swift, Vala, and I think C#. Certainly Visual Basic.

You are right @alcinnz, #JavaScript was never "designed".

It's a 10 days #hack added to #Netscape in a rush to beat #Java.

And then people wonder why it sucks...

@xj9 @mcread @strypey @aral @bob

@alcinnz @aral @strypey It's also important to distinguish between web apps and web pages.

A website for a restaurant is not an app. It doesn't need Javascript. I'm disinclined to enable JS for it just to see their phone number.

A website that is acting as a Matrix client? That's acting as an *app*, and I'm more inclined to enable JS. Of course it can run code, just as I would allow a native app to do.

(My *ideal* would be sandboxed native apps shipped with a standard package manager.)

> My *ideal* would be sandboxed native apps shipped with a standard package manager.

Isn't that basically what #WebExtensions are?
@alcinnz @aral

@varx @alcinnz @aral @strypey

It's not the same of an application.

When you download an application, you can compare it's cryptographic hash with that got by your friends. Usually you don't need to authenticate to download so the chance you get a malicious version specifically crafted for you are lower.

With a #WebApplication any #CDN that the developers trust could customize the code you execute exactly for you.

And sandboxing is not enough.

@Shamar @varx @alcinnz @strypey 1. Download an app from the App Store.

2. Check its hash how, exactly? The developer doesn’t even know it.

With a client-side-only JS app:

1. Include a single script file using subresource integrity.

2. Publish the hash of the HTML file for independent verification.

3. Use a browser extension to verify the hash of the HTML.

You’ve verified the app.

@varx @alcinnz @strypey

Not yet enough to be safe, @aral, but a good starting point: bugzilla.mozilla.org/show_bug.

If the application is completely client side (never does any network connection) it might be enough.

Otherwise further restrictions should be in place and they require changes to the browsers: bugzilla.mozilla.org/show_bug.

@varx @alcinnz @strypey @aral

As for the App Store, I'm pretty sure the installer already check the hash transparently for the user.

But I was thinking about applications that are manually installed by users by downloading them.

The fact that the server that provide the file cannot identify the user (hopefully, if they don't use #GAFAM #cloud services or #Cloudflare's #MitM) is a protection to the downloader: an attacker cannot easily target a specific person or a minority.

@Shamar @alcinnz @strypey @aral Yes, this is why I said my ideal is to use a package manager, which allows 1) public naming of versions, and 2) user control over which version is in use.

Sandboxing, in the way I'm thinking of, can go beyond what browsers normally do. There's no reason you'd have to allow sideloading of random scripts and resources.

@varx I sometimes contact the webmasters / editors of activist and independent media websites to ask if they knew about all the scripts from third-party domains that #NoScript has to block for me when I visit their sites. Often they have no idea. I suspect that often scripts are being called by off-the-shelf JS modules built into #WordPress themes and the like.
@Shamar @alcinnz @aral

Sign in to participate in the conversation
Aral’s Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!