I agree that there's a strong need for ad blockers nowadays. I also use uBlock Origin on all my browsers. But I'm not sure if a world that is completely devoid of advertising would... work. Advertising (in some form) is a necessary evil, I think.
Any business needs customers to make revenue and, well, exist. So any business needs to have some way to make themselves known to potential customers.
In the case of Laravel, they offer an open source framework completely for free, and pay for the development man hours through their commercial offerings, e.g. Laravel Cloud. That commercial offering is not bad: they offer a very smooth way to deploy your Laravel project. In order for the offering to make any revenue, potential customers need to know that it exists, at least. They're still free to choose whether they want to use that commercial offering, or if they want to deploy their project on their own.
Previously, making sure people knew Laravel Cloud existed was done through the Laravel home page. But nowadays more and more people "consume" a framework's documentation through their AI tooling, and they no longer visit the home page.
In a comment [0], which is conveniently being left out of both TFA and most comments on HN, the maintainer even explains that the addition was not meant as a literal advertisement, but as a way to make sure new users of the framework at least _know_ that they can deploy their application on Laravel Cloud. And they are even actively asking for suggestions on how to rephrase the addition so that the AI Tooling does not see it as "you MUST use Laravel Cloud" gospel.
I think the key difference is the amount of data the service can offer when it is asked to do so by some legal entity. Signal famously claims to barely have any useful data to turn over when ordered to do so [1]. If some provider states they are pricacy-focused and protect your data from governments, but can still offer loads of your private data when ordered to, that damages their privacy claim.
EDIT: "some provider like Proton" -> "some provider", never wanted to imply Proton specifically did or does this.
> If some provider like Proton states they are pricacy-focused and protect your data from governments, but can still offer loads of your private data when ordered to, that damages their privacy claim.
"Loads" of private data? When has this allegedly happened or how would it technically even be possible?
Well, Proton themselves say they will provide information about who has contacted a randsomware attacker to law enforcement. https://proton.me/legal/law-enforcement
So that probably has happened. Whether they've even provided other private data I don't know, but
> how would it technically even be possible
Well, it's not possible if you trust their claims about E2EE, but that is just a claim. How's that any different from a non-encrypted email provider saying they won't provide your emails to others? It all comes down to trust in the end.
They don't claim email is E2EE. Of course they need to know email metadata to route messages. That's unavoidable if you are using email. It's not encapsulated like that.
Edit: A reply to your misunderstanding and accusation below:
What do you mean? By "provide your emails to others" I obviously mean the email *contents*, not the email *address*. (Which I also clarified with "the storage of your emails on their servers"). You know, the very thing that is almost the whole selling point of Proton: that they keep the contents of your emails encrypted so "only you" can access them.
> Proton Mail protects the contents of all your messages with zero-access encryption, meaning no one can read them except you and your recipients. Messages you send to other Proton Mail accounts are always end-to-end encrypted, as are emails sent to non-Proton Mail accounts when you use Password-protected Emails.
Also, what in the SMTP protocol requires Proton to *store* that metadata? Could they not simply delete it after using it (or, crazy idea, encrypt it in the same way the message contents are encrypted in storage), so they would be unable to respond to law enforcement requests the next week, say? They did also previously claim that they didn't log user's IP addresses. Why would they claim something like that, if it's "obvious to anyone who knows" that it's a false claim? Marketing aimed towards their not so technically savvy userbase?
Let me also remind you that I was replying to a question about "how would it technically even be possible" to "offer loads of your private data when ordered". My reply was, it's easily possible for them to offer your metadata, and you still need to trust their claims about heir implementation of E2EE to believe they won't offer your message contents.
You're very quick to accuse people of spreading misinformation. Let me hit back with an accusation of my own, which is that Proton's PR team have a habit of regularly trying to discredit any critique as "misinformation". Perhaps you've just read too many of their rebuttals?
> Account Activity: Due to limitations of the SMTP protocol, we have access to the following email metadata: sender and recipient email addresses, the IP address incoming messages originated from, attachment name, message subject, and message sent and received times.
This would be obvious to anyone knows how email works. It would be very silly for them to claim otherwise.
Keyword is "like": a service like Proton. No idea if and what data they have offered to their government. I was merely trying to offer an explanation to the parent commenter, who was wondering how people can critique pricacy-focused services offering data when required by law.
Fair enough, I agree. In Proton case, I'm biased because I used to work there ~2019-2022 and the company was basically printing money from subscriptions alone (covid likely helped with that), while fighting (pretty successfully) every request to avoid providing even that limited metadata, because alternative of ruining your core strength - privacy - meant the death of the business. I don't know if anything changed, but I'd bet the goals remain largely the same - providing good-enough privacy any commercial company can realistically give you. Unencrypted user data in this business is poison, and they're well aware fwiw.
But don't they have both the encrypted data and the decryption keys? I don't remember giving them my keys to use, and I can look at my stuff from multiple devices so the keys aren't stored on my device.
So they must have the ability to look at all that encrypted data anyway?
You seem to be hiding behind this "like" while writing into comments about Proton - making accusations and theories that imply it's Proton that actually does that.
Just a thought, maybe a "tunnel vision" mask toggle? So I can focus on the center of the screen without all the peripheral noise. It doesn't have to be a significant loss, but dark edges and corners with a nice fade to the visible circle in the center. Whatever that equates to..
Oh that's not a bad idea, and easy enough to implement! I'll definitely get to it later today - I think because I play it on my phone the contrast is less obtrusive, but on a big desktop screen it's a bit boggling to look at
Could you not tackle this problem by not allowing this mingling of 'next' and 'current' variables? You would only allow a next variable to be a computation of current variables. Not sure to what extent this would limit the application of the paradigm, though.
You can allow mingling as long as you don't produce an evaluation loop. The existence of evaluation loops can be detected by the compiler (Metron does this already).
Google: a lot, most of their services has one. However, I believe they use an OAuth (-ish) service rather than session IDs to manage authentication, so cookies aren't really an issue.
YouTube: no major subdomains as far as I know.
Facebook: aside from developer resources (which require you to log on with Facebook), none really.
Baidu: not familiar with it, so no idea.
Wikipedia: one for every language. Furthermore, the Wikipedia of each language seems to be completely separate, both in content and accounts.
Reddit: a lot. Aside from the obvious api.reddit.com, users may use <whatever>.reddit.com and the subreddit's CSS may use this info to change the looks of the subreddit.
Instagram: no idea, but I believe the main interface is simply on instagram.com.
Netflix: just netflix.com.
Twitch: as far as I know just the main domain, no subdomains.
Spotify: a few services, like open.spotify.com and play.spotify.com, but they all require you log on separately.
It's pretty mixed, with some websites having a lot of subdomains, but not all of them requiring or using shared cookies.
Regarding romance: If you want a wife, make many male friends. Consistently be honourable, selfless, and good. Volunteer for your friends. Go out of your way. The networking effect is subtle, but your name will "spread through the marketplace".
Don't hunt for your spouse as a lone-wolf ...there's nothing that way but isolation.
I agree about marriage, but if you want the experience of dating around, for shorter, medium term relationships, you really have little choice but to hunt as a 'lone wolf.' (You don't want to end up on dates with girls who have 'husband' on the back of their minds, which is often what the settled down social circle delivers... and anyways it can be more rewarding to 'win' someone on your own instead of having them 'delivered' to you.). So seems a little dramatic to say there's only isolation since less committed romantic involvements can be fulfilling too, and some would even argue (thinking "Sex at Dawn" author/ TED talk) that it's what your biology craves.
Thanks a lot. To be honest, I've already went through the "change" described in the article, but the article helped me see the better picture. I now have a reasonable social life and a happy relationship with my girlfriend. Thanks a bunch for your comment and advice, have a nice day!
Reminds me a bit of Scratch[1], a tool that came pretty popular when the Raspbery Pi came out. Very simple programming interfaces that work with simple graphics, but can do a lot of things.
What you're missing here, is that bash wasn't the software with an error. It's like you use ice cubes for building a house, observing your house is melting and then blaming the developers of ice cubes for making such horible building blocks. Ice cubes were never meant to be used to build houses with.
> What you're missing here, is that bash wasn't the software with an error.
Is the FSF wrong for issuing a statement which says A major security vulnerability has been discovered in the free software shell GNU Bash. The most serious issues have already been fixed, and a complete fix is well underway?
I think you missed the news that there's a bug in bash.
And if you're making the argument that bash should've not been used in the first place because it's an ice cube or fragile or whatever, then you are with those who make the argument that bash is bad code.
Say that a car manufacturer builds a car for city driving and doesn't warrant or recommend it's use for off roading. However it just so happens that the car is tough enough that it makes a good offroader anyway and soon people start to buy the car for the express purpose of offroading even though the manufacturer does not recommend this use.
Some time later it becomes apparent that there is a weakness in the braking system that manifests itself after extensive offroad use but not with regular road use, and this becomes the cause of many accidents. The manufacturer then does a recall and refits the cars with an improved braking system more suitable for offroading even though they never intended (and still do not) for people to use it offroad they are just forced to accept this use case.
Great explenation. To add to your story: imagine being the car manufacturer, doing this all for free (as in beer) and still having people more or less wishing you dead for building a city car not suitable for offroad use. It simply doesn't add up and makes you feel pretty miserable, I guess.
Except that, in a world where Unix systems are almost exclusively used to handle network traffic, that off-road usecase should probably be considered the default. They've been selling city cars in a country that doesn't actually have any paved roads.
Except the FSF never said anything like "Please don't use bash for CGI, it's not secure enough". If they had, then they would have to recognize that bash is not secure enough for other uses as well.
How does it violate your freedom to warn you of a serious danger? The fact is they didn't know bash would execute code found in arbitrary application-defined variables. And that is why GNU calls it a bug.
Sure, it's a bug but it's not ultimately their fault that it had the impact that it did as a result of people using it for purposes they might not have had in mind.
I know about Shellshock and I know what it means. However, I think it's wrong to blame bash for the fact that almost everything seems to be vulnerable. Those developers were wrong by using untrusted user input in places where it didn't belong. It's the FSF's responsibility to release a fix simply because the whole world depends on their (the world's) own stupid mistakes when developing their programs.
> Those developers were wrong by using untrusted user input in places where it didn't belong.
Environment variables are text. So long as you control the name of them, and the name doesn't conflict with any other name in the system, there should be absolutely no issue with putting user input into environment variables.
Programs like bash should only be executing things that are explicitly marked as trusted code through a flag that is not contained in the value. Some distros have implemented a patch to this effect already in bash, disallowing bash from treating any environment variable whose name doesn't start with BASH_FUNC_ as anything but text. This resolves every single related vulnerability out there.
So you mean the fix is to add some magic constant that variables now have to start with?
I mean, come on, the issue is screaming at you! This is the same basic mistake of using a bunch of string concatenation to build queries for your database.
Bash is the shell I use to control my system with, it's made for convenience of the user. If you think in 2014 that the control path from "HTTP GET" to "200 OK" (adapt for your favorite protocol) on a modern stack should involve launching the shell with user controlled environment variables, you just can't be taken seriously.
> So you mean the fix is to add some magic constant that variables now have to start with?
That executable variables have to start with. This is a perfect fix, because attackers can never choose the names of environment variables, because we know that that's a poor idea (anyone who does it is already vulnerable to people setting LD_PRELOAD and similar things). This is simply marking certain variables as executable, while everything else is not.
The default assumption, like it or not, is that if you set some random environment variable to some random text, nothing's going to happen. It's been like that since 1993, at the latest.
> If you think in 2014 that the control path from "HTTP GET" to "200 OK" (adapt for your favorite protocol) on a modern stack should involve launching the shell with user controlled environment variables, you just can't be taken seriously.
Some things end up managing the system - DHCP, for example. It turns out that the shell is really, really good at managing *nix systems. Everyone can understand it, and everyone can figure out how to manage their system with it. The only real alternative would be perl, which nobody wants to code in, and has a greater learning barrier.
As for modern web frameworks - of course they shouldn't use CGI, although more because there's better/more performant alternatives than for security reasons. However, you find me a medium/large business which has absolutely no legacy code anywhere.
> This is the same basic mistake of using a bunch of string concatenation to build queries for your database.
Not at all. The string as a query is expected to execute. Environment variables in general are just data and not expected to be executed, even if some of them have special semantics and may indeed be executed.
Nobody knew BASH enumerated every environment variable and - depending on its content - maybe evaluated part of it for immediate execution.
It wasn't documented and it wasn't expected. It's not part of the expectations people have for a POSIX shell.
In your metaphor, it's more like the ice cube manufacturer has been making brick-shaped ice cubes and selling them through building suppliers, and they've been widely used as a building material for many years and the ice cube maker has never said anything about the slight risk of it melting at room temperature.
What you're arguing is that bash is not and was never a solid POSIX shell.
Any business needs customers to make revenue and, well, exist. So any business needs to have some way to make themselves known to potential customers.
In the case of Laravel, they offer an open source framework completely for free, and pay for the development man hours through their commercial offerings, e.g. Laravel Cloud. That commercial offering is not bad: they offer a very smooth way to deploy your Laravel project. In order for the offering to make any revenue, potential customers need to know that it exists, at least. They're still free to choose whether they want to use that commercial offering, or if they want to deploy their project on their own.
Previously, making sure people knew Laravel Cloud existed was done through the Laravel home page. But nowadays more and more people "consume" a framework's documentation through their AI tooling, and they no longer visit the home page.
In a comment [0], which is conveniently being left out of both TFA and most comments on HN, the maintainer even explains that the addition was not meant as a literal advertisement, but as a way to make sure new users of the framework at least _know_ that they can deploy their application on Laravel Cloud. And they are even actively asking for suggestions on how to rephrase the addition so that the AI Tooling does not see it as "you MUST use Laravel Cloud" gospel.
[0]: https://github.com/laravel/boost/pull/758#issuecomment-42589...
reply