> It's at most a basic "anti-annoyance" feature, I'm not sure what security you gain from preventing everyone from messaging you.
This could be a long conversation. The short version is there are plenty of articles online by marginalized groups talking about the consequences of having no ability to block arbitrary groups from harassing them online. If someone is calling that "just an annoyance" they've likely never been the target of an extended public harassment campaign.
A slightly longer answer is that the consequences to privacy and security are in a practical sense -- in the sense that someone coming into my house is a violation of my security and privacy. Privacy is not just about hiding information, it's also about why we hide information. It's about the ability to be private; to not be forced to constantly listen to a bunch of people shout at you. Similarly, security exists for a reason, we have security in our homes in the sense that people can't just walk into them and start yelling at us and harassing us. And DMs should be thought of as analogous.
Your DMs are not secure if you have no way to turn them off or restrict them.
> The ability to block users was always there and it still there for free.
If you recognize that is important to privacy and security to be able to block individual users, it's not too hard to recognize that the requirement to individually block users leaves a huge gaping hole in security for a network that supports open registrations.
I use disposable email addresses rather than just blocking individual spammers in my email client. The reason is because there are a near-infinite number of spammers and blocking them one-by-one is ineffective. Being able to turn off a leaked email address is much more valuable to me. It's something that actually cuts down on spam.
And the same is true on social media -- being able to go private and turn off messages or restrict messages to certain subgroups is critically important for people who are stuck in the middle of public harassment campaigns.
----
Regardless, the lack of a feature that is pretty much standardized across most other platforms, and that is pretty widely recognized as a safety feature -- it doesn't make me feel better about Telegram's willingness to gate these kinds of features behind paywalls.
You're saying that the ability to block users is free, but there is no bright line between blocking users and setting general messaging restrictions. That is the same category of safety feature. There's no reason to believe that Telegram wouldn't make blocking users into a paid feature in the future, especially since it has demonstrated that blocking/moderation/lockdown features are something it is willing to monetize.
Because it's Facebook, I can't say that they aren't planning that.
But if anyone else mentioned this tech, I would assume it was benign. Subresource Integrity (https://developer.mozilla.org/en-US/docs/Web/Security/Subres...) is primarily aimed at servers proving to clients that their code is unaltered, not the other way around. I haven't personally tried it before, but I can't imagine why extensions wouldn't be able to override integrity strings or remove them from script elements.
For WhatsApp I'm not sure I see the point necessarily, but it's an understandable goal for Open Source and offline webapps or for apps that use 3rd-party CDNs. The main problem for personally hosted code is that the integrity string is also getting served from the server, so there's no reason it can't also be altered if the server that gives the HTML is compromised.
In theory with some tweaking and a way to pin integrity strings in a user-controlled way (which an extension could do I suppose) it could be a step towards allowing users to know when a PWA is being updated, which would be helpful for some security models. In its current state it's fairly niche and I'm not sure how useful the standard is outside of securing CDN requests.
Although why that would matter to WhatsApp, :shrug: It does feel weird that Facebook would be leading that push.
> And before that you just weren't able to restrict that at all
This is a really basic security feature though that every single platform should support. If Telegram didn't support messaging restrictions before, that doesn't mean they're not currently gating a basic privacy/safety feature behind a paywall. It just means they should be embarrassed that they used to be doing something even worse, ie not even offering a basic privacy/safety feature at all.
Correct that this would not technically count as removing a feature, but I feel like that's possibly a distinction without a difference. I'm not coming out of reading this explanation feeling more charitable about Telegram's security or willingness to gate off security features. It's a bad look for a company to put basic blocklists behind a paywall, that is not a company I trust not to start degrading security for free users.
But that is the job. The job of developing on the web is developing for a platform where you do not know the size or format of the display or what the inputs are in advance.
The job of a UX designer on the web is to consider this kind of stuff and to build a design that's very reactive to evolving displays within the demographics and market segments that the client wants to support. If that's not happening, if the CSS people are just getting handed static designs and being told to figure it out -- the problem is not CSS or the developers, it's that the designers building those designs are not good at their jobs. And there are ways to make this easier: notably UX designers involving the CSS department in the design phase, and/or making a point to always lay out the contents of the page without styling in a hierarchical way before making decisions about how to present that content.
But a lot of programming is hard. It's hard for me to write maintainable Javascript that doesn't fall apart if a project goes over 100,000 lines of code. It's hard to document methods. It's hard for me to write code that does complicated things that can work on low-end machines. These are skills that programmers get better at over time with practice. Responsive design is the same; it's just another skill to learn.
Imagine trying to shoot a movie and having the cinematographer tell you that it's hard to frame everyone in the shot since they don't know exactly where the viewer will be looking, or the sound mixer telling you it's hard to balance dialog and sound effects so everyone is audible without it being noticeable that they're muting background audio. Or a recorder telling you that it's hard to master a pop song given that everyone has different speakers and sound profiles on their headphones. Imagine you're building a car and the designer tells you that it's hard to make sure the controls can be reached by people who are different heights and weights.
On one hand, yes it is; all of that stuff is very hard. On the other hand, yes, that is also the reason web UX designers and developers get paid money; because the job is hard and requires training and expertise, and designing a website interface requires more thought and intentionality and planning than is required to make a PDF.
I think that differing device resolutions and aspect ratios in some ways forced designers to think about things that were always worth thinking about but were easier to ignore. I use a tiled window manager, I care about whether your desktop site is responsive even at minimal widths because I tile windows. I also have a touchscreen monitor hooked up to my desktop and I like to be able to use it. And sometimes I also full-screen windows on a 32-inch screen and use a mouse-and-keyboard. If a desktop site accommodates me in all of those scenarios, it'll probably be fine on a phone as well.
But it was so easy in the past to just ignore that and treat PCs like they were uniform devices used in a uniform way, and phones meant that you suddenly had to care about what a website looked like in a single-column view, you couldn't just tell your users to maximize the browser window. Unfortunately, rather than taking away the lesson that design should adjust to nonstandard situations, layouts, and input-modes that can not be fully predicted or tested for in advance -- instead developers took away the lesson "okay, now there are two standard devices we have to support: mobile and desktop."
The distinction isn't real, there is no hard line between a desktop and a mobile site. There are mobile tablets that are big enough that they should be served a desktop layout, there are desktops with touchscreen displays, there are monitors that are 3/4 ratios. And there never was a standard and computers were always like that, but it's an understated truth that every developer and every designer would secretly love to develop exclusively for consoles with integrated screens and one input method, and developers often kind of behind-the-scenes somewhat resent the fact that general computing is an open ecosystem with diverse devices. So designers often just treat computers like they have two completely discrete interfaces, or at worst decide that because they're not targeting one of them that they now have permission to target exactly one resolution and size again.
Sometimes that takes the form of designing "mobile only" like the top-level comment talks about and calling desktops a dead platform. Sometimes it means designing desktop only and getting mad that somebody flipped their monitor vertically instead of horizontally and now wants the ability to move a side-drawer to the bottom of the screen.
That I completely agree with -- I've had a hot-take a couple of times in the past and I still hold to it, that regardless of what HTML was intended to be or not be originally, today it's at its best when it's treated as a user-facing rendering target, and a lot of the criticisms about HTML's ability to handle things like giant virtual lists are missing the point that you shouldn't have giant lists in your UX in the first place, you shouldn't have a DOM tree that lists out 20,000 options in a `ul` if you're treating HTML like it's a user-facing interface rather than an authorship format for the developer alone.
I'm still honestly a firm believer in the design technique of designing the HTML of a website before I start working on the CSS, and I know that a lot of people call that naive or say that it doesn't work... but I'm not saying that you can't revise the HTML later to fit a design, just that first I want to know what the content is and I want to treat the HTML as a primary rendering target, not an authoring language. I think there are a lot of benefits to that (one being that in addition to being more user-controllable and flexible, it also makes it much easier to do responsive design if you approach web design through that lens because page layouts become views of a unified block of content rather than completely separate isolated designs).
But I don't think including the CSS is where that process falls apart or that it's disrespecting the user or denying agency. It's like how if someone hands me a image of a block of text, my problem is not that the contrast in the image is too light or that it's the wrong color; my problem is that they handed me an image of a text document. If someone hands me a website that is so intrinsically tied to CSS that it's impossible for me to easily adjust column widths, that coupling is the problem more than the column widths.
Firefox does have some some great options around CSS control for partial or small adjustments but in typical Firefox fashion its best features are all hidden like Mozilla is embarrassed of them. I didn't bring up userContent.css to be dismissive; genuinely you should take a look at it if you've never used it before. I make heavy use of it for websites, everything from building grayscale modes when I want a website to be less distracting, to swapping layouts around. But it's a valid criticism that it's not user-facing and you need to go into advanced settings to even enable it. Browsers could do more.
> As a user, when I set my browser to be full screen, I expect the content to take up the full screen. I bought a nice big 27" monitor, and I want to use it. How dare some UX designer 2,000 miles away from me simply decide that I should only be able to see content on a 5" wide strip down the middle!
I've seen this argument come up before multiple times on HN, and it's wild to me. Having sensible CSS defaults is not a designer dictating that you are only able to see content one way. You might prefer to read text in a giant line spread across a giant monitor, and that's fine, but it's not a freedom thing. It's not denying your browser's role as a user agent that sites have CSS files.
Every single website (HN included) makes CSS decisions for the user. What colors should be used, what is the default contrast. Every single line of CSS on a website is a designer decision by a designer 2000 miles away from you about how they think that content should be presented. And if you don't like that, turn off CSS in your web browser. Assuming you're using Firefox (which you should be using), it's trivial to do.
Of course, browsers should allow overriding CSS, and (imo) they should make it easier to do so and more accessible to non-technical users. And yes, part of making a website that respects the browser as a user agent is shipping HTML that can be viewed unstyled and that is easy to override styles for. Ironically, HN does a horrible job of this -- the HTML is not semantic, the use of tables is so egregious that even stripping the CSS out doesn't really remove all of the styling. The site is really messy if you want to override anything. So that HN uses a design that happens to more closely align with what you want does not make the site more respectful of your browser as a user agent. It just means that you and the designer(s) happen to like the same design.
And in comparison, putting `max-width: 45em` on a text column is not even remotely user hostile, it is a very simple CSS property to override -- especially for designs that use single columns because you can change that CSS property without even worrying about reflow. `max-width` is a default that statistically works better for the majority of users even on large monitors (I use a 32 inch 4K monitor and max-widths make text on that monitor easier to read). But of course, some people are different, and that's fine. Go yell at the browser makers to allow easier CSS overrides, or turn off CSS entirely, or install an extension that lets you add CSS to given pages or spend a weekend building an extension that strips max-width out of stylesheets for every website you visit, or customize Firefox's userContent.css file. There are options here. And if you had made an argument about those options, I'd be 100% on board. CSS for websites should be treated as a default setting instead of as a requirement and browsers should support CSS overrides more easily out-of-the-box.
But the idea that designers are denying user agency by not making a proactive design decision to present by default the specific format you want to read -- it's just ludicrous. You're not asking for user freedom, you're asking for designers to target your preferences instead of other people's. Those two things are not the same.
Yep, I see this in both directions. People are still of the mindset that "desktop" means a single resolution and aspect ratio that everyone uses. That wasn't really the case in the past, but it's really not the case today.
- On Linux, the assumption is that everyone has a 1920x1080 monitor, so if you get a high resolution 13-inch device like a Surface suddenly half of the apps are unusable because everything is scaled so tiny, and the apps literally just do not know how to handle the aspect ratio.
- On Web and in popular design studios, the assumption is that everyone has a full 4K mac and so everything becomes larger and spread apart; you load them up on a normal monitor and everything becomes cluttered and the interface of the app starts taking up more room than the content you're looking at.
Test your apps on multiple resolutions y'all, and for the love of everything that is holy if you're designing a desktop app, please add button density and font size controls to your settings. Some weirdos like me even use multiple monitors of different resolutions and pixel densities hooked up to the same computer at the same time, so being able to adjust on the fly or handle fractional scaling is kind of a big deal for apps that I use. Standard resolutions are a myth.
It's not just that it makes the web less powerful, it also makes it less private and less user-controllable. There is no effective way to build an offline webapp that handles important data, if you're building a website that handles actually important data -- that data is getting synced to an online account.
As a result there are a number of web-apps that could be entirely account-free and offline that aren't. It also makes it a lot harder for users to move and transform data, although maybe that's less of a consideration nowadays since mobile has kind of standardized data silos even for native apps that would have previously had portable databases or worked directly with files.
Not saying you should want it, I completely understand and am completely sympathetic to anyone who says "the benefits don't outweigh the risks." That is a fine position for someone to take. That being said, this isn't just about trying to make the web more powerful, it's also in a lot of ways about fixing long-time deficiencies in the web that have made it less private and that forcibly shift the majority of even well-intentioned web software into a user-hostile SaaS model. When every webapp is a SaaS business with web accounts, that decreases hobby development in favor of corporate development and encourages users to spread their data in (imo) irresponsible ways.
This is what people like me have been getting at for ages when we talk about decoupling interfaces from application logic. It's also incidentally a really strong argument for decoupling state presentation from visual presentation. I should be able to build a mobile interface for Audacity without rebuilding Audacity both because the audio processing logic should be separate from the interface and because the interface should be separate from the visuals -- I should be able to consume Audacity's interface as an XML tree and pipe it into a separate renderer.
Because if that was the case it wouldn't be that hard to make Audacity mobile friendly (or at least more mobile friendly than it currently is).
As a bonus, if your interface is consumable as an XML tree without rendering anything, it's very likely going to be much easier to make the interface accessible. From what I can see in the documentation, Audacity as a native app on desktop doesn't work with screen readers on Linux.
This is not necessarily anyone's fault beyond GUI toolkit designers, it's not particular to Audacity, but it's a paradigm shift. Some visual controls wouldn't work well on mobile, but for most apps including Audacity there's really no reason (other than lack of existing infrastructure and toolkit support) why people shouldn't be able to just swap out those visual controls with ones that do work on mobile and use Audacity normally otherwise.
Persistent read/write access to user-defined folders rather than only to private origins.
You know how everyone complains about Flatpak sandboxing until they learn about portals and Bubblewrap because the programs are isolated from the rest of their disk? The web is like that, except without portals and Bubblewrap. You can save stuff and drag files in, but you can't really integrate a webapp with a user's local filesystem -- and it's very hard to keep all of a webapp's data in a user-inspectable format that's easy to transform, open up with native apps, or transfer across browsers or websites.
Now, the problem is that persistent read/write access to user-defined folders is wildly dangerous. And Google's proposal is... not the worst thing in the world? But it's suboptimal and it's a missed opportunity to build something far better, and I kind of understand why Mozilla considers it harmful.
Getting this wrong would have permanent implications for the web. Mozilla is absolutely right to be cautious. However, it's also really holding the web back and in particular holding back PWAs because the only really reliable way as a developer to store data via the web is to sync it to an online account. As a result offline webapps are very limited; you never really trust the storage.
It's an extremely dangerous feature that we really need, but it's not clear who should champion it and I don't really trust Google to be heavily involved in the spec process, let alone to be the people writing the first draft. I don't think Google is good at building nuanced web specs even when there's no conflict of interest at all (see the web audio API, HTML templates, etc...). A lot of Google specs end up being very weird and they end up having strange quirks and very strange limitations that don't need to exist? They're very often kind of orthogonal to what the community needs. I don't know if the problem is that Google doesn't think enough about the spec or that they think too much and over-complicate things, but for low-level important features I prefer other browser-makers to lead the way.
What would be best is if a team with more earned trust picked up the spec and went over it again trying to better address the dangers and trying to make something that better addressed everyone's needs in a cleaner way, but there are not a ton of stakeholders on the web that I trust to do that. As it stands the proposal is... ok-ish? But needs a lot more discussion and could be better. I don't blame anyone for being hesitant about it; the potential for abuse is so unbelievably high.
But... it is a serious limitation that I can't ask for persistent read/write access to a folder from an offline webapp.
It is a general comment about Linux. Arch Linux is a major distro, if people using Arch can't run Linux software using existing packaging systems, the packaging systems are broken.
If the natural result of existing packaging systems is that software only works on distros like Ubuntu and Fedora, then that is very much a general Linux problem.
I suspect GoG tests mostly on Debian-based systems, probably Ubuntu and it's variants. On Arch, things get weird (at least in my experience, maybe other people have had better luck).
It's frustrating because Arch is generally more stable for me than Debian, but you can kind of see the niche status of the OS play out whenever you're working with a package that wasn't packaged by the Arch team. When developers have to maintain packages for multiple distros, my experience has been that usually the popular ones get serviced first and the niche ones get serviced last.
I would love to as well, if the Linux versions would boot up and run on Steam Deck. Even when I was gaming on my desktop, which is pure Arch, I remember regularly needing to edit Linux games or recompile dependencies to get them to work.
Flibitijibibo has some good commentary on when to dynamically/statically link libraries, leaning towards statically linking dependencies when possible to avoid relying on the OS too much. Coincidentally, Flibitijibibo's Linux ports are some of the few where I can just download them and be confident that they're likely going to work out of the box with zero troubleshooting.
> The major distros and BSD have shown, that yes, that scales fairly well in fact given the number of apps provided through distros official repos.
I mean... citation needed :) I run Arch and I am not dismissing at all the frankly incredible work that the Arch maintainers do bundling software and making it available. It is a miracle that it works as well as it does, to the point where my Arch systems are often more stable than non-rolling-release distros I occasionally run. Fantastic work by the maintainers.
But it's not a solved problem and I can only imagine how much effort and work is getting burned to keep it running as smoothly as it does. Step outside of the official Arch repos into AUR or (heaven forbid) into completely separate ecosystems and all of those problems come back. And I don't want to ignore the software outside of the repos, I didn't start using Linux so that I would be beholden to some kind of "official" distro app store.
There are tons of Open Source applications with no legal barriers in place that are not getting packaged in official repositories for no other reason than that they're niche and there is a lot of software to package and not enough people to do package it all.
And of course any non-OS games are also going to run into these problems. That's a problem that distro maintainers can't solve, it doesn't matter how much work they put into it, they can't repackage source-available or closed source software. "People shouldn't ship that" -> but they do :) So ideally we'd be able to handle that without descending into dependency hell.
> No, the main reason is that the linux versions do not exist for the most part
I'm not talking about games where the Linux versions don't exist, I'm explaining why I'm currently running the Windows version of Inscryption on my Deck even though it has a native Linux port. Do I want to be doing that? No, of course not. But the Linux version doesn't boot, most likely because there's some dependency chain missing or an environment variable is wrong, or... I don't know, I don't want to crawl through forums and debug that myself, I want to play the game.
And I'm not alone in that, it is common advice on Linux to use Proton instead of Linux native versions. And that stinks, it's bad for the ecosystem and it's bad for users and it's bad for games. But the Linux versions have so many more problems because they make assumptions about the underlying system that turn out not to be true. Of course Windows builds also have those problems, but the difference is that they run in a containerized environment that gives them the system they expect.
> But on the other hand, app crashes aren't something that common on linux. I mean at least on my distro
Strong disagree, my experience is that app crashes are extremely common on Linux if you step outside of official repositories; I say this as someone who literally only runs Linux and nothing else. I'm not necessarily saying Windows is better but... it's not like nothing ever breaks. It's impressive how well developers are able to hold it all together, but my experience is that Linux systems are fragile the moment anyone stops actively managing the dependencies and putting in the work to compile everything to match.
> that is not packaged by the distro maintainers
It is not feasible or scalable for Linux for every single app (even every Open Source app) to be distributed and managed by the distro maintainers. And this is what I'm getting at with dependency isolation -- the vast majority of crashes and bugs I see on Linux (and I mean by a massive margin) are all due to dependency mismatches and shared dependencies. A lot of Linux software is generally stable if the system looks like what it's expecting the system to look like. But if you're not going through an official repository where a bunch of volunteers are putting in the work to make it consistent, then it very often doesn't look like what developers expect.
This is why people run games through Wine instead of using the Linux versions -- it's not because it's impossible to build good native versions, it's because if they don't use the Linux version they can use Bottles. That's the biggest reason; it's about the dependency isolation.
I guess millage may vary, the only thing I can say is that there are multiple instances (particularly GoG which the article seems to praise) that literally never work on some of my systems.
The few times I've run into Flatpak crashes, they're architecture problems that would have been present in any version of the app, so I'd be doing that work regardless. They're harder to debug in Flatpak, but also heck debugging crashes every time I try to install a piece of software. I'll happily take the added complexity of needing to boot a shell into the sandbox if it means I get to debug 50% fewer problems (and in practice Flatpak tends to reduce my number of issues by way more than 50%).
The average user is never going to open a debugger, minimizing the number of crashes is more important for that user than making the crashes easier to debug.
This debate will never die, but while people have been complaining about it, Flatpak has quietly just become a better way to package software for end users. My criteria is that I'm a user, I don't care about what's elegant to developers -- and I have fewer problems with Flatpak than I have with non-Flatpak software. The vast majority of Flatpak problems I do have as a user come down to sandboxing permissions that I actually quite appreciate. The (very) few architectural problems are problems I would have had with other bundling systems too.
"Developers are lazy" -> No, no user ever wants to debug dependency issues, and developers can't get rid of dependency issues. This feels like a repeat of the Rust debates where C developers kept complaining that good developers just don't have memory errors. Okay whatever you're very talented, congratulations; but most software isn't written by people who can reliably support multiple distros and lowering the skill requirements to maintain software is good actually because I use hobby projects all the time. Even outside of hobby communities, GoG's Linux installer is so borked that half of the time it's easier to install the Windows versions of the games and run them through Wine (because then you can use Bottles which provides dependency isolation). And I am completely convinced that dependency management is the problem -- Flatpak apps don't have these issues, at least not nearly as many.
I'm not saying everything should be a Flatpak, but certainly at the very least most Linux games should be, anything that's graphical that isn't being distributed through an official package manager is a good candidate to at least consider Flatpak. I'm always grateful when I can install a graphical app through Flatpak instead of AUR.
Is it the future? Flatpak critics spend a lot of time bashing Flatpak and very little time proposing equivalent fixes or acknowledging why Flatpak exists in the first place. If those issues were solved and the solutions popularized on mainline distros, maybe Flatpak wouldn't be the future. But I'm not holding my breath. This article proposes GoG's system as an alternative and says the existing problems are minor and easy to solve. 2 years later, I have literally never gotten a GoG native Linux installer to run without problems on the Steam deck.
I'm not even saying it has to Flatpak, but whatever system you want to propose (Snap, AppImage, whatever) very clearly dependency isolation is better for end users and results in fewer bugs. "It takes up too much space" just isn't a real critique when the alternative being proposed almost universally fails to run on my hardware.
I'm pretty nervous about Passkeys for exactly these reasons, and I'm still not at the point where I feel comfortable advocating for them, but I'm forced to admit that if anything, Apple has (so far) arguably done the best job of any of the major tech companies at discouraging vendor lock-in with Passkeys.
Blocking attestation requirements, opening up 3rd-party providers earlier, and (I'm not sure if it's released yet) committing to search. I even saw recently that they're releasing Chrome/Edge extensions for Windows to sync keys.
Do I trust it? Ehhh... I still can't generate passkeys on Linux as far as I know, so I'm definitely not going to be using them any time soon no matter what. There are still articles like this pointing out abusable features that I'm not sure should even exist in the first place. And it's honestly just going to be a while for me to get over the weird amount of advocacy that so drastically misunderstands what portability even is in the first place (no, 1Password does not make passkeys portable, standardized export/import formats as a requirement for certification make passkeys portable).
But I think the signs are that Apple is caring a lot more about avoiding vendor lock-in than Google/Microsoft are right now, which is a very weird thing for me to say.
> Sure, you can refer to them in explicitly vague terms, like "cloaked figure" or "person". You still use gendered language, only now it corresponds to that of the abstract noun you're using. [...] "room mate", "won", and "recovered" are all gendered, and you can hardly pretend you don't know who they are without looking insane or obviously hiding something.
Right; while English has more ambiguous tools, even in English many speakers will think it's a bit weird to keep using "they" to refer to someone if you do know what their gender and pronouns are. (For many listeners at least), it wouldn't be natural-sounding dialog/conversation for me to describe my sister exclusively with the word "they".
I'm not saying that in casual conversation people would use ambiguous language -- but there are scenarios where you'll have conversations about something you saw where you don't at any point during that conversation have any knowledge of the genders involved, and of course the language has support for scenarios like that.
Agreed that English has more tools for explicit ambiguity; if you see a car fly off a bridge, you can say, "I hope they're OK." But even if you weren't using 'they', you could say "I hope he's OK" in that situation and the majority of people around you would understand that using the word 'he' wasn't a declaration that you knew who was in the car. The movement away from "he" as a default gender in English wasn't because without singular 'they' there was no support for situations where the gender was unknown, it was a movement away from the social/political/moral implications of default gender in society, and later became expanded into a way to explicitly accommodate nonbinary speakers and avoid misgendering.
I got curious about this and tried to look it up, and while the explanations were a bit limited, my takeaway is that it does seem like the Russian language works the same way? If a car flies off a bridge and you use masculine language to talk about the driver, and then later find out the driver was a woman, my understanding is that people probably aren't going to be offended about that or think that you've done something odd? At the point where you learned the driver was a woman you'd just quickly apologize and switch to feminine forms.
This could be a long conversation. The short version is there are plenty of articles online by marginalized groups talking about the consequences of having no ability to block arbitrary groups from harassing them online. If someone is calling that "just an annoyance" they've likely never been the target of an extended public harassment campaign.
A slightly longer answer is that the consequences to privacy and security are in a practical sense -- in the sense that someone coming into my house is a violation of my security and privacy. Privacy is not just about hiding information, it's also about why we hide information. It's about the ability to be private; to not be forced to constantly listen to a bunch of people shout at you. Similarly, security exists for a reason, we have security in our homes in the sense that people can't just walk into them and start yelling at us and harassing us. And DMs should be thought of as analogous.
Your DMs are not secure if you have no way to turn them off or restrict them.
> The ability to block users was always there and it still there for free.
If you recognize that is important to privacy and security to be able to block individual users, it's not too hard to recognize that the requirement to individually block users leaves a huge gaping hole in security for a network that supports open registrations.
I use disposable email addresses rather than just blocking individual spammers in my email client. The reason is because there are a near-infinite number of spammers and blocking them one-by-one is ineffective. Being able to turn off a leaked email address is much more valuable to me. It's something that actually cuts down on spam.
And the same is true on social media -- being able to go private and turn off messages or restrict messages to certain subgroups is critically important for people who are stuck in the middle of public harassment campaigns.
----
Regardless, the lack of a feature that is pretty much standardized across most other platforms, and that is pretty widely recognized as a safety feature -- it doesn't make me feel better about Telegram's willingness to gate these kinds of features behind paywalls.
You're saying that the ability to block users is free, but there is no bright line between blocking users and setting general messaging restrictions. That is the same category of safety feature. There's no reason to believe that Telegram wouldn't make blocking users into a paid feature in the future, especially since it has demonstrated that blocking/moderation/lockdown features are something it is willing to monetize.