Is that really what this is about? I feel the GDPR is a different thing, independent of the cookies popup being a browser standard or not. The article talks about altering the definition of "personal data". I don't see why you can't keep the same definition while requesting websites to follow a browser standard... so I feel these are different things.
Or are you implying that the EU doesn't get proposals to gut privacy/data protections? (regardless of whether they're accepted)
The "formal" part comes from "formal system", which is essentially the use of rules of inference based on an initial set of presuppositions, with an exact/mathematical approach to "truth".
The idea of "informal logic" is something some people have wanted to put forward, but it's a much younger and not as well defined term, and whether it should really be considered "logic" is something that has criticisms: https://en.wikipedia.org/wiki/Informal_logic#Criticisms
Perhaps in the end all logic is formal logic, the problem is that we know from Gödel's incompleteness theorems that not everything is computable and translatable into a formal system.. to solve this you'd have to model the statements into a Gödel/Lobian machine (at which point you are essentially building an AI).
You're not being fair, that wasn't the conversation thread at all.. I didn't reply to OP's initial message directly.
It was more like this:
- OP: Hi guys, I’m looking for yellow tomatoes, do you know where can I get them?
- Commenter: I go to this store, they have tomatoes that are yellow enough for me.. for more sophistication you need to go to a much further away local shop.
- OP Response: My question isn't sophisticated! ...all I want is my tomatoes to be of the same color as all the other yellow vegetables I exclusively eat, all yellow, tomatoes and ketchup being red is a step in the opposite direction.
- Me: there's a reason why the red ones are sold, [valid cultural reason]. But you can still change them, here's a manual / recipe to turn them yellow when cooking.
As you see, when I was talking about reasons it was mainly directed to the apparent indignation of comment "3", when the person was painting their request as something that should be seen as the more reasonable / less sophisticated approach.. so I gave the reason to show how the opposite is also more reasonable / less sophisticated from another point of view.
But even then, I did link to the manual for readline to configure the input handling. It's not like I just dismissed the initial question like your simplification implied.
PowerShell still runs inside a terminal emulator (e.g. Fish), so it changes nothing in the input/output behaviour.
You can definitely change the behavior by changing the program that runs on the terminal... in fact, when I posted that link earlier, what I said is that you can configure this in readline, which is a library that bash and many other programs that run in the terminal (not all, not fish, for example) use for interpreting the input, so all terminal programs using the readline library for handling interactive input have the same shortcuts. It's not the terminal the one with those shortcuts coded into it.
“GUI-friendly terminals”? What does that mean, in the context of the conversation? Why are you talking about GUI?
Because a terminal emulator is a GUI app... OP wasn't talking about about real terminals, nor about a virtual console session in Linux (which runs without any GUI), but about a terminal emulator you open in a window within a graphical compositor.
My point was that most of the popular (amongst terminal nerds) GUI app terminals stay away from the traditional GUI toolkits when possible because they want to keep the app slim and lightweight. And it's those toolkits the ones that orchestrate the standardization of the typical Windows-like shortcuts (similar as the readline library, but for GUI apps). This is also why in many terminals you don't even have a menu when you right click, since those menus are usually done with GUI toolkits. But there are also heavy-weight terminals like the ones bundled in some more user-friendly DEs that do include GUI toolkits as dependencies, so they might actually have an easier go at playing nice with other conventions in their respective DEs. However, you'd still need to pair it with a shell that also plays nice (or configure it to play nice, if possible).
Is it weird to explain the reason why something is as it is? If you were already aware of it then it shouldn't be as baffling.
There are also modern terminals and shells that do things the way you expect in a more convenient way, but maybe you also know this, OP mentioned powershell, that can be used in Linux too. It's just that this hasn't been a focus for traditional and slim/lightweight terminals coupled with traditional shells which is typically the popular combination amongst heavy terminal users, many of the slim terminal apps stay away from GUI toolkits that are what normally give consistency in settings to the GUI apps. And because they are slim and try to eliminate what isn't absolutely needed, typically they don't do configuration profiles, specially given that it's relatively easy in Linux to backup and reuse your configuration across installs. It's more of a job at the OS/sysadmin level.
There's also not a real standardized setup in Linux as a whole. There are environments that default using the Super (Windows) key for all window management, or use TUI terminal apps for most things so they get terminal navigation keys for all their apps. Some people even configure Gtk/Qt to use vim/emacs style for navigation in text boxes because for them it's the other way around, all their apps use terminal shortcuts because.. well.. they are terminal apps.
You are probably right.. it's just one hope I had, I'm not expecting it to happen, but I'll be hopeful until the end.
Hope for the best, prepare for the worst.
The thing is that vi and emacs have existed since long before those other new editors came around.
What you want is possible to do by configuring your ~/.inputrc (see readline manual page for details), it's just that the defaults are different because they are from a time when many keyboards didn't even have arrow keys (and the ones that had them were in non-standard positions) so most of the shortcuts that became standard in those days are completely different than the ones common today. Given that the terminal is meant to emulate old style DEC VT100 terminals (that's why it's called terminal "emulator") it made sense to use those default that people had grown used to.
Personally, I've grown used to Ctrl+a, Ctrl+k, Ctrl+w, Ctrl+e and Ctrl+y ..I dont have to reach to wherever the Home key is in whatever keyboard I happen to be using at the moment (specially with modern 75%/60%-sized keyboards today). Or use a combination that also requires shift and having to hold so many keys together. In fact I went the opposite direction and customized my Powershell profile while I'm on windows to keep many of those old shortcuts in the Windows pwsh terminal as well.
The thing is that Apple is even worse when it comes to its walled garden practices and locked-in bundled software. For example, in Android you can at least choose amongst alternative apps for SMS, etc. And some are even open source, and available in the official store. But in Apple devices you can't compete with iMessage, by policy. It's simply not allowed. Even from a technical standpoint it's not possible either, since they don't even offer an API for a third party iOS app to handle SMS/MMS/RCS. And that's just 1 example.
So you are jumping from the pan to the fire if you go from Android to iOS. Even if you are ok giving up the "sideloading" aspect, you are still worse off with Apple anyway.
Will the banks in Korea, EU and many other areas where Samsung phones are very common keep that restriction if it meant alienating that many users? I doubt it. That's why I think the support of a big player on this would be a killing move.
Also I'm not 100% convinced that it's impossible to have some verification without it depending on this one change.
I mean, you can hack/root most devices, even right now. I expect that's not changing.
I'm not sure if that would be viable technically.
They might be able to make requestable the connection requests to outside sources (which I expect is something many extensions use, even those without data collection), but whether those requests relate to data collection is not something that can be determined programmatically.
Samsung s22 and s25
I'm still holding some hope that maybe Samsung's flavor of the OS won't have the restriction of requiring Google keys. Specially considering that Samsung has its own "Galaxy Store" with app submissions controlled by them, not Google.
Though it's possible they might simply extend the signatures accepted to include also the ones signed by them ^^U ..still it would give them a competitive edge to remove the restriction so they might be incentivized to do it.
Yes, it also narrows down the number of potential targets for analysis / report. If an extension is not marked "none" then no need to go out of your way to figure out if it does it.
For some extensions it might actually be relatively easy to figure out if they do communicate with an external server that they might not need to, specially considering that the extension format can easily be decompressed, .crx files are just zip files with some javascript and other files inside.. they might want to obfuscate the logic, but it's not impossible to try and unravel things to some extent.
I've commented it in the other post, but in my opinion, the issue of the "nothing to hide" -> "no worry in showing" statement is that in between lines (specially in the context for which it's used) it seems to want to imply that having something to hide must be something rare or perhaps wrong.. as if it were not possible to want to hide things that are good for society to keep hidden.
This isn’t a formal, logical fallacy, but an informal one: https://en.wikipedia.org/wiki/Informal_fallacy
From a perspective free of presuppositions and biases, I don't think the logic of the argument on itself is wrong, because of course I wouldn't be worried about my privacy if I had no interest in keeping my private information hidden.... but the premise isn't true here! the context in which the argument is used is the problem.. not the logic of it.
It's not incorrect to say: "nothing to hide" -> "no worry in showing" ...what's incorrect is assuming that the "nothing to hide" antecedent is true for all law abiding citizens ...as if people didn't have an interest in keeping perfectly legal and legitimate things hidden and safe from as many prying eyes as possible. The fallacy is in the way that it's used, they are pretending that this means people shouldn't be worried, when in fact it means the opposite, since everyone does, in fact, have information that should remain hidden. For our own safety and the safety of our society! ..so everyone should in fact be worried about breaches in privacy.
In my opinion, this looks more like an informal fallacy, the problem is in the context and the intent that is given to the statement, not so much in the logic of it.
The postulate has some ambiguity.. because in between lines it seems to want to imply that having something to hide must be something rare or perhaps wrong.. as if it were not possible to want to hide things that are good for society to keep hidden.
This isn't a formal, logical fallacy, but an informal one: https://en.wikipedia.org/wiki/Informal_fallacy
From a perspective free of presuppositions and biases, I don't think the logic of the argument on itself is wrong, because of course I wouldn't be worried about my privacy if I had no interest in keeping my private information hidden.... but that premise isn't true here! the context in which the argument is used is the problem.. not the logic of it.
It's not incorrect to say: "nothing to hide" -> "No worry for showing it" ...what's incorrect is assuming that the "nothing to hide" antecedent is true for all law abiding citizens ...as if people didn't have an interest in keeping perfectly legal and legitimate things hidden. So it's not that the statement isn't logically sound, the fallacy is in the way that it's used, they are pretending that this means people shouldn't be worried, when in fact it means the opposite, since everyone does, in fact, have information that should remain hidden. For our own safety and the safety of our society!
It's more like calling "nazi" to all forms of authoritarian positions, even the left-wing authoritarians in the opposite side of the spectrum.
There's a distinction between "informal fallacy" and "formal / logical fallacy". Both have separate articles in wikipedia as well. Why not just call it "fallacy" without categorizing it into a specific subcategory it does not fit anyway?
And even if they did somehow manage to get permission to switch the license, all previous versions would still be open in perpetuity so a fork would come easily. Immich source isn't only open, and not only GPL.. but AGPL-3.0 which is as copyleft as you can get.
Yes, last time I tried Revolt it looked shamelessly like Discord's UI.
I feel that if they just wanted an app with the look and feel of discord, it would have made more sense to make a matrix (or maybe xmpp) client with the look and feel of discord. I honestly don't see much value in yet another protocol if the only distinctive feature is in the look & feel of the UI. Specially if they are not designing the stack in a way that is at least as good as those other options from a security, privacy, feature extensibility and decentralization standpoint.
Did they work on developing new web standards to unlock that potential on the web?
Back then HTMLv5 wasn't even a thing, there was no concept of video/microphone/gyroscope/gps access for webapps, notifications, web workers, web sockets, offline PWA webapps, etc. It was not a viable idea unless they actually were to invest big. They weren't so committed. In Firefox OS even the dialer was a webapp, Mozilla brought forth a lot of innovative APIs to make it possible, many of which are in use today even after the OS was discontinued. And nowadays you even have things like Webassembly that allows you to code it in C or whatever low level language you want.
I feel Apple has always been more interested in their own ecosystem. Opening the web to have the same level of potential as the native apps from their walled garden goes against that strategy, so I don't believe they were really serious about that approach, it's always been more interesting for them to prioritize their native apps.
Enforcing the restriction through a browser web standard, instead of a popup susceptible to anti-patterns, is a good idea. Sure, you could configure your browser to say "yes to all", but you control the browser. You could also configure it to say "no to all" if that's what you want. It'd be the equivalent of a popup, just automated by you. It's the way I always thought the cookie permissions should have been done. The same way as when a website asks about permissions for notifications, or camera/mic access.
But I don't think this is what the article is talking about. They are not talking about using a web standard or anything like that, they are talking about how the very definition of "personal data" is being changed, and that does not look good.