I think a lot of this might be covered in just a new, possibly graphical browser client.
For example, a browser that rejects the style sheet provided by the site, and instead renders the page using the user supplied style sheet(s), in order to send site control back to the user, for presentation, as it was supposed to be to begin with.
And, of course, refusing to execute code on a drive-by basis. People rail against Java, but the benefit there was there was always a clear distinction between what the browser was serving, and what was served via the jvm was ever present, which makes things much safer.
Intermingling js and html into a monolithic rendering engine was the mistake.
From there, once js and stylesheets are removed from the equation, this is when a good user-experience can be had, that lacks commercialization of every user experience.
The web always had a commcerical component (IBM was an early adopter to it, and developer, for example), not every interaction was monetized, and therein lies the issue. It’d be hard to monetized all interactions if there was no js rendering in a browser, and users were allowed to customize the presentation in their own client.
Well it only partially addresses the problem, following Google’s best interests. AMP was only a problem for website operators when it came to advertisement. Apart from such commercial concerns, AMP was just another web proxy, with its own dialect (because cooperating on advancing web standards would not advance Google specifically).
The culture of centralized gateways that AMP promotes is actually mostly a problem for end-users, for both censorship and surveillance concerns. I don’t know if it’s a problem where you reside, but for most of the world political repression and censorship are very real problems.
Google and Facebook have both tried in their way to create their private walled garden. And they’ve been very successful at that so far. Tying discovery to delivery in a centralized manner is a very subtle form of total control.. this is one of the possible futures of the internet, but for sure a scary one.
They saw a problem (people not being able to check that the site they’re reading is actually the site and not what Google says) and they fixed it, and now you’re complaining that the problem’s fixed? I swear, some people…
That’s really sad but how are to rely on containerization tools if most official images introduce new security problems? Traditional distros seem to have higher security standards.
I would draw the line slightly further down the slope from you. If I need to use proprietary firmware to have a functioning computer, okay. If I need proprietary firmware for a chance at an essential function of the computer, okay then. If using only FOSS stuff would be a massive pain in the ass (defined as a road that isn’t a road but just a collection of sharp and jagged rocks)? I may just use the proprietary solution.
Basically, my philosophy is “FOSS or OSS where possible” (down to coding my own stuff sometimes if I can’t find it) and proprietary if necessary.
For example, given the choice between open-source Gambatte and proprietary BGB, I’ll take BGB all day. (Especially because beware, the dev, is open to bug reports and basically only keeps the code to himself because it’s in Pascal he doesn’t want endless forks.)
If I need proprietary firmware, I will (All CPUs load proprietary microcode, after all). If I have a choice, even if it’s a rocky road, I’ll pick the FOSS solution.
I mean, I just use a Chromebook (biting the Google bullet because it’s fine) with an Ubuntu chroot. The length some people go to to use only FOSS software is ridiculous sometimes. I would have bit the bullet on internal wifi. If I have to buy a USB dongle to use something as simple as WIRELESS INTERNET, I’d rather not use the platform at all.
That makes it surprisingly easy to deploy otherwise complex services such as applications that depend on Web services. For instance, setting up CGit or Zabbix is a one-liner, even though behind the scenes that involves setting up nginx, fcgiwrap, etc. We’d love to see to what extent this helps people self-host services—sort of similar to what FreedomBox and YunoHost have been focusing on.
AMP “Real” URL: encouraging browsers to deceive us
CloudFlare and Google teamed up to develop a standard way to let your browsers lie about who’s behind your URL.
CloudFlare was already a master at impersonating websites by terminating TLS connections on their servers, but now they’re proposing that browsers connecting to an AMP cache (Google or CloudFlare) should lie about the URL, i.e. display https://tilde.news/foo instead of https://google.com/amp/….
They hide behind some crypto to make it look secure, but the problem is deeper. If we can’t trust our browsers to display the URLs we’re talking to, what can we trust? Hopefully this will be one more reason for people to drop out of Chrome and Google reach.
Awesome. I like the idea of Forth, but haven’t yet found a reson to use it for anything.
All these people clamouring for a new graphical gopher client are tempting me to make an electron monstrosity.
I think a lot of this might be covered in just a new, possibly graphical browser client.
For example, a browser that rejects the style sheet provided by the site, and instead renders the page using the user supplied style sheet(s), in order to send site control back to the user, for presentation, as it was supposed to be to begin with.
And, of course, refusing to execute code on a drive-by basis. People rail against Java, but the benefit there was there was always a clear distinction between what the browser was serving, and what was served via the jvm was ever present, which makes things much safer.
Intermingling js and html into a monolithic rendering engine was the mistake.
From there, once js and stylesheets are removed from the equation, this is when a good user-experience can be had, that lacks commercialization of every user experience.
The web always had a commcerical component (IBM was an early adopter to it, and developer, for example), not every interaction was monetized, and therein lies the issue. It’d be hard to monetized all interactions if there was no js rendering in a browser, and users were allowed to customize the presentation in their own client.
Well it only partially addresses the problem, following Google’s best interests. AMP was only a problem for website operators when it came to advertisement. Apart from such commercial concerns, AMP was just another web proxy, with its own dialect (because cooperating on advancing web standards would not advance Google specifically).
The culture of centralized gateways that AMP promotes is actually mostly a problem for end-users, for both censorship and surveillance concerns. I don’t know if it’s a problem where you reside, but for most of the world political repression and censorship are very real problems.
Google and Facebook have both tried in their way to create their private walled garden. And they’ve been very successful at that so far. Tying discovery to delivery in a centralized manner is a very subtle form of total control.. this is one of the possible futures of the internet, but for sure a scary one.
…Really?
They saw a problem (people not being able to check that the site they’re reading is actually the site and not what Google says) and they fixed it, and now you’re complaining that the problem’s fixed? I swear, some people…
That’s really sad but how are to rely on containerization tools if most official images introduce new security problems? Traditional distros seem to have higher security standards.
I would draw the line slightly further down the slope from you. If I need to use proprietary firmware to have a functioning computer, okay. If I need proprietary firmware for a chance at an essential function of the computer, okay then. If using only FOSS stuff would be a massive pain in the ass (defined as a road that isn’t a road but just a collection of sharp and jagged rocks)? I may just use the proprietary solution.
Basically, my philosophy is “FOSS or OSS where possible” (down to coding my own stuff sometimes if I can’t find it) and proprietary if necessary.
For example, given the choice between open-source Gambatte and proprietary BGB, I’ll take BGB all day. (Especially because beware, the dev, is open to bug reports and basically only keeps the code to himself because
it’s in Pascalhe doesn’t want endless forks.)which means that it is also extensible with Lisp thanks to fennel-lang.org
I draw the line on firmware.
If I need proprietary firmware, I will (All CPUs load proprietary microcode, after all). If I have a choice, even if it’s a rocky road, I’ll pick the FOSS solution.
I mean, I just use a Chromebook (biting the Google bullet because it’s fine) with an Ubuntu chroot. The length some people go to to use only FOSS software is ridiculous sometimes. I would have bit the bullet on internal wifi. If I have to buy a USB dongle to use something as simple as WIRELESS INTERNET, I’d rather not use the platform at all.
Great idea. I’m sure somebody will be doing it soon enough!
Awesome!
Soon to be, a tilde server based on GNU Guix?
I don’t understand the point of encryption providing at least 1/K chance of decryption, or did i get this wrong?
CloudFlare and Google teamed up to develop a standard way to let your browsers lie about who’s behind your URL.
CloudFlare was already a master at impersonating websites by terminating TLS connections on their servers, but now they’re proposing that browsers connecting to an AMP cache (Google or CloudFlare) should lie about the URL, i.e. display
https://tilde.news/fooinstead ofhttps://google.com/amp/….They hide behind some crypto to make it look secure, but the problem is deeper. If we can’t trust our browsers to display the URLs we’re talking to, what can we trust? Hopefully this will be one more reason for people to drop out of Chrome and Google reach.
If they go to a proprietary solution, it’ll be the death of the foundation.
via: https://tiny.tilde.website/web/statuses/101987595193855103
Who wants ZIL installed on tilde.team?
Much better than the small selection I was carrying on my gopher hole :)
https://libpqcrypto.org/ for anyone that wants to use post-quantum crypto now.
https://libpqcrypto.org/ for anyone that wants to use post-quantum crypto now.