Recent searches
Search options
Mozilla is the “socially acceptable” face of Big Tech.
For example, Google and friends know you’d never “donate your voice” for whatever their next privacy eroding product is. So thank goodness they don’t have to ask you. Because an entity they invest ~ half a billion dollars into every year and which you trust (maybe it’s time to review that choice?) can ask you instead.
So Mozilla creates a voice dataset and licenses it liberally so any surveillance capitalist like Google, etc., can use it.
@aral I totally agree that this seems to be the stance of big tech now. As a Firefox user though we have no where else left to go. What's the communities next move to counter this you think?
@rustygopher I hear you. I can’t speak for the community but this is what I’m working on: https://small-tech.org/research-and-development :)
@aral Oh wow this looks amazing, so happy I actually found out about this I hope to see it develop further. Will be keeping an eye on it and supporting you.
@rustygopher Thank you :)
@aral
If it's based on Site.js, doesn't that mean it relies on JS and thus isn't good for privacy or older machines?
@rustygopher
@dheadshot @rustygopher No, it doesn’t mean that because there is nothing inherent in JS that “isn’t good for privacy” or runs badly on older machines. On the contrary, keeping your secrets on the client (which you control) *requires JS* and requires that all logic runs on the client and that the server (which you don’t control) is as dumb as possible and never has your secrets. Sadly this generic dogma about “JS is dangerous” is perpetuated by folks like the FSF and it’s both wrong and harmful.
@aral Client code is served from its server so to control the client you have to control the server anyway. Keeping most of logic in the client will eventually slow it down, as well as sometimes unnecessarily complicating the setup with APIs and ways to keep in sync, and it gets worse if you get into hybrid rendering to speed things up.
Look at sites like Sourcehut or Invidious, they work fine without JS and are still usable. [1/2]
@aral I'm not saying that JS is true devil but making your site break without JS is bad. For example, some users only have access to text environment (no GUI) and JS won't work in text-based browsers like lynx, w3m and friends.
[2/2]
@yyp And that’s fine. Those folks will not be able to use the Small Web. Every system has minimum requirements. The ones for the Small Web may not work for Richard Stallman but they are perfectly fine for everyday people who use technology as an everyday thing.
@yyp PS. I’m boosting some of my replies because this is a point that’s come up several times now so I want other folks to read and understand what we’re building and why :)
@yyp For Small Web we treat the server as an app download. We can verify the download out of band (eg., via a browser extension) to rule out tampering by the host if that’s within your threat model. Otherwise the security depends on your secrets never leaving a space you own and control. So we MUST implement it in JavaScript. We CANNOT implement it on the server.
JS isn’t the enemy. Someone else (Big Tech/people farmers) holding your data and keys is the enemy.
@aral do you know if signing of JS (or other assets) is a thing already? I mean I know about Subresource Integrity, but that's just a hash. I mean a way to SIGN a file, so that a browser(-extension) could verify (perhaps from DNS TXT) that this is the very file a developer intended, regardless where it's hosted and if SRI is in place?
@aral basically with the same properties that apps currently verify signatures with (TOFU, and a file can only be replaced by one the is signed by the same key(s) and so on)
@claudius Been looking into it quite a bit. Nothing to sign the initial download. So we’ll have to have a browser extension + dev/build workflow conventions.
@aral
Yeah, so it's complicated, right? Just downloading and running apps randomly isn't good for your privacy or security–turning off (or not supporting) JS makes sense as a general rule for how to make devices more secure/private. However, JS is great for making apps less reliant on the server and more useful offline or with static hosting. How else can you make an app that runs on everything and doesn't require expensive hosting?
@dheadshot @rustygopher
@aral, I don’t think the @fsf has ever issue any statement similar to JS is dangerous. I think its official stand is only against non-free software, which includes client-side code. GNU LibreJS is recommended by the foundation instead of disabling JS all together.
Cc: @dheadshot and @rustygopher
Free Appalachia@michal Wasn’t impressed by their ethical stance. Going to give librefox a shot when I get a moment.
@aral You say We’re building the Small Web. It also says Trust the client. Does that mean that the client is not a browser? What is your opinion about fixing de-Googled Chromium, would that be an option?
@gert I mean the client as in a web client but yes, good question: what does it mean when we can’t trust apps that run on our own trusted devices? But insofar as the threat model for the small web goes, I think we can trust that not even Chrome would circumvent specific encryption implementations in JS or exfiltrate passwords.
PS. Why does Ungoogled Chromium need fixing? (It definitely needs work to make it easier to install.)
@aral I also wonder if it's time do review that choice. But maybe it's one of those slightly open doors we have to change big tech? Would it be too naive to think like that? Maybe so. But maybe we need a face we can face?
@aral I mean, isn't it better to do it openly through Firefox than Google using voice chats and video conferences in "Google Workplace" or something to do it under the hood?