@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?

smashingmagazine.com/2012/06/m

@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.)

@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.

@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.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!