How would he do that? The tax breaks for health care are as far as I can tell extremely popular in the US, both with employers and with employees. It would be political suicide and would never get through Congress or Senate.
For example, why shouldn't my neighbors and I form a pool and buy a group policy similar to that of my employer?
Because you get taxed before you get to do that, whereas almost everyone else gets to buy their healthcare with before-tax income. You will not be able to gather enough pools to make it a mainstream product.
The problem is that you are not actually free to buy your own insurance, because if the employer does it for you, they get to use pre-tax money to do so, whereas you have to pay tax first. There are other problems too of course, since health care bought by individuals is so much more expensive, it is a niche product, and niche products are usually expensive in a mass market economy. Still, the fundamental problem is the tax issue.
That actually makes the problem worse. Once you have forwarded your X connection with ssh -Y, everyone who can get the security token on the machine you ssh into (e.g. at least root) can sniff your keystrokes. If you do ssh -X instead, the damage they can do is limited (well except for X bugs), but few things actually work so -X is rarely used.
X is pretty unique in that respect, other remote desktop protocols generally do not have local keyboard sniffing built in as a feature (although I think some of them have had bugs enabling it).
If you need, I can perform benchmarks for you of Ubuntu viewing an application on another Ubuntu machine over X11 and Ubuntu viewing the Windows version of the same application over RDP.
Feel free to do so, but dbIII only cares about outdated applications not using modern toolkits. X has a great advantage over RDP/VNC/etc. when it can do the text rendering server-side. No modern applications use server-side text rendering, of course.
It is actually becoming a bit of a hassle to travel by air without electronic devices these days. Airlines requiring that you check in online, print boarding cards or bring them on your smartphone etc. For the most part this is tremendously useful, but if the travel involves the UK or the US it suddenly becomes a problem.
I do not agree with you that fine grain protection is disabled in Android. I love that apps show me which permissions they expect. The only thing I want more is to be able to deny them those permissions even when they ask for them. I use third party tools for that, but it is admittedly not the perfect solution.
How are you going to build the Pairwise Master Key at bootup if you do not have the plaintext key? Many (most?) networks have an authentication timeout, so just storing the PMK is not a complete solution.
With SELinux you can run with a completely useless root account if you prefer. Unix security has traditionally been a complete joke, but the Windows low-level design is not particularly better. What would you like instead of Unix? AS/400 or zOS perhaps? I do not think either of them can handle graphical applications, but I could be wrong. Adapting them for widespread client-side use seems challenging.
Fine, just do not click the button to make the connection system-wide. Then NetworkManager works exactly as you want. However, the password is still available in plain text form at authentication time, in the widget where you typed it.
If you do that, NetworkManager does the right thing.
Not that I have ever seen an office network configured that way, but I am sure they exist. It must be annoying to have a smart card reader glued to your phone though.
No. An additional password isn't pointless. It is the purpose behind the operation of gpg-agent, KNetworkManager, Firefox's master password, LastPass and several other programs.
NetworkManager uses the system wallet for per-user passwords. If you tell NetworkManager to store the password around so it can connect before user log in, it is hardly surprising that it does exactly that.
Asking for the impossible does not help anyone. Publicizing the lack of response just makes you look like an ass. Particularly if you manage to go public on a forum full of technically knowledgeable people like Slashdot. (Yeah right).
NetworkManager uses the keyring if you keep the passwords user-only. As soon as you enable the connection to start without any user being logged in, a wallet is useless.
What exactly does it help that they are encrypted? The system can obviously decrypt them, otherwise it would not be able to use the passwords at all. Therefore the encryption is just obscuration, and it might lead people to apply insufficient protection to the files themselves in the belief that the contents are not sensitive.
You cannot hash wifi passwords. The password needs to be available in plain text form at authentication time. Root can always get to the unencrypted bits, no matter which weird obscuration mechanism you try to use. Even if you require the user to type in an unlock key every time, root can sniff the key.
Mandatory access control like SELinux or AppArmor can actually provide some security in this case. Sprinkling magic encryption dust cannot.
Local inflation does not matter when making investment choices. The choice is: either I keep the money in my pillow and earn 0% safely, or I invest it and earn X% with a risk. Inflation being -10% or 200% does not change whether the investment is worth doing.
Losses are tax deductible. It is definitely worth it for less than 10%, and taxes do not change that.
It is so strange that across the western world you can pretty much avoid tax as long as you can prove that you gained the money without doing anything useful for it. As soon as the tax system thinks you may actually have developed a few beads of sweat on your forehead in the process of acquiring the money, you get hit hard.
People who get money for nothing are not going to stop getting money for nothing just because you start taxing their gains. In contrast, people who work for their money might not bother putting in that extra hour if they know that they will lose a good portion to the tax man.
OK I give up. I think anyone who might happen upon this thread now has a clear idea about which part is based on experience and which part is based on ignorant speculation.
The R&D site has a massive base-station so that the phones would lower their transmission levels, thereby preventing the cancer of course.
Similarly, us in the telecoms industry have a conspiracy where we convince school boards that radiation is dangerous and get all wifi removed plus base stations placed far away. This ensures that the phones emit the high levels of cancer-inducing radiation needed to properly mind control the children.
At home those who are in on the conspiracy even place base stations right in their homes, in order to protect themselves! You probably have one of those deceptively-named "femtocells" too.
Radio waves don't just get absorbed when passing by some matter, they have to be of the right energy.
Water will absorb an extremely wide band. Contrary to popular belief, 2.5GHz is NOT a special resonant frequency for the water molecule, pretty much any cell phone band would work fine for microwave ovens. 2.5GHz was picked for engineering reasons, not out of physical necessity.
Are you seriously asking that question? If you are get the original owner of your user id to explain it to you.
Yes I am seriously asking that question. I need remote X for legacy apps approximately once a year. I need remote X for modern apps daily. Except modern apps do not work over remote X, so I use other protocols. Which again means that blaming Wayland for taking away the X ability to handle remote displays is disingenuous, because X does not handle remote displays either for anything more modern than xeyes.
Legacy apps are not interesting. They will by definition not start supporting other protocols, if they did, they would not be legacy. Therefore there is no point catering to them for new protocols such as Wayland. All that is needed for legacy applications is to give them an old-fashioned X server running in a window, just like OS X does. OS X handles remote X display of legacy X applications absolutely fine, and XWayland does it pretty much the same way. Wayland has feature parity with X for remote display already.
If it's in the same city it should be about that let alone on the same local network! Don't blame X when your latency is an order of magnitude higher than it should be.
Welcome to WLAN. I am not going to use a cable to get around the shortcomings of the X protocol. The desktop is dead, get over it.
True, rootless mode is the one advantage that X has over VNC.
Full integration is a bit of a stretch though. Only the basic X integration like simple clipboard and so on works. D-bus is not available through the X protocol, so proper GNOME integration is not possible. The forwarded applications are placed in their own little D-bus sandbox living on the remote machine, with no access to the D-bus that local apps use.
Slashdot Mirror
Fair enough, let us see if we can get the people complaining about the plain text passwords to buy Yubikeys. It is a sensible choice, for sure.
How would he do that? The tax breaks for health care are as far as I can tell extremely popular in the US, both with employers and with employees. It would be political suicide and would never get through Congress or Senate.
For example, why shouldn't my neighbors and I form a pool and buy a group policy similar to that of my employer?
Because you get taxed before you get to do that, whereas almost everyone else gets to buy their healthcare with before-tax income. You will not be able to gather enough pools to make it a mainstream product.
The problem is that you are not actually free to buy your own insurance, because if the employer does it for you, they get to use pre-tax money to do so, whereas you have to pay tax first. There are other problems too of course, since health care bought by individuals is so much more expensive, it is a niche product, and niche products are usually expensive in a mass market economy. Still, the fundamental problem is the tax issue.
That actually makes the problem worse. Once you have forwarded your X connection with ssh -Y, everyone who can get the security token on the machine you ssh into (e.g. at least root) can sniff your keystrokes. If you do ssh -X instead, the damage they can do is limited (well except for X bugs), but few things actually work so -X is rarely used.
X is pretty unique in that respect, other remote desktop protocols generally do not have local keyboard sniffing built in as a feature (although I think some of them have had bugs enabling it).
If you need, I can perform benchmarks for you of Ubuntu viewing an application on another Ubuntu machine over X11 and Ubuntu viewing the Windows version of the same application over RDP.
Feel free to do so, but dbIII only cares about outdated applications not using modern toolkits. X has a great advantage over RDP/VNC/etc. when it can do the text rendering server-side. No modern applications use server-side text rendering, of course.
It is actually becoming a bit of a hassle to travel by air without electronic devices these days. Airlines requiring that you check in online, print boarding cards or bring them on your smartphone etc. For the most part this is tremendously useful, but if the travel involves the UK or the US it suddenly becomes a problem.
I do not agree with you that fine grain protection is disabled in Android. I love that apps show me which permissions they expect. The only thing I want more is to be able to deny them those permissions even when they ask for them. I use third party tools for that, but it is admittedly not the perfect solution.
How are you going to build the Pairwise Master Key at bootup if you do not have the plaintext key? Many (most?) networks have an authentication timeout, so just storing the PMK is not a complete solution.
With SELinux you can run with a completely useless root account if you prefer. Unix security has traditionally been a complete joke, but the Windows low-level design is not particularly better. What would you like instead of Unix? AS/400 or zOS perhaps? I do not think either of them can handle graphical applications, but I could be wrong. Adapting them for widespread client-side use seems challenging.
Fine, just do not click the button to make the connection system-wide. Then NetworkManager works exactly as you want. However, the password is still available in plain text form at authentication time, in the widget where you typed it.
If you do that, NetworkManager does the right thing.
Not that I have ever seen an office network configured that way, but I am sure they exist. It must be annoying to have a smart card reader glued to your phone though.
A casual observer should not have root access to your machine.
No. An additional password isn't pointless. It is the purpose behind the operation of gpg-agent, KNetworkManager, Firefox's master password, LastPass and several other programs.
NetworkManager uses the system wallet for per-user passwords. If you tell NetworkManager to store the password around so it can connect before user log in, it is hardly surprising that it does exactly that.
Asking for the impossible does not help anyone. Publicizing the lack of response just makes you look like an ass. Particularly if you manage to go public on a forum full of technically knowledgeable people like Slashdot. (Yeah right).
NetworkManager uses the keyring if you keep the passwords user-only. As soon as you enable the connection to start without any user being logged in, a wallet is useless.
What exactly does it help that they are encrypted? The system can obviously decrypt them, otherwise it would not be able to use the passwords at all. Therefore the encryption is just obscuration, and it might lead people to apply insufficient protection to the files themselves in the belief that the contents are not sensitive.
You cannot hash wifi passwords. The password needs to be available in plain text form at authentication time. Root can always get to the unencrypted bits, no matter which weird obscuration mechanism you try to use. Even if you require the user to type in an unlock key every time, root can sniff the key.
Mandatory access control like SELinux or AppArmor can actually provide some security in this case. Sprinkling magic encryption dust cannot.
Local inflation does not matter when making investment choices. The choice is: either I keep the money in my pillow and earn 0% safely, or I invest it and earn X% with a risk. Inflation being -10% or 200% does not change whether the investment is worth doing.
Losses are tax deductible. It is definitely worth it for less than 10%, and taxes do not change that.
It is so strange that across the western world you can pretty much avoid tax as long as you can prove that you gained the money without doing anything useful for it. As soon as the tax system thinks you may actually have developed a few beads of sweat on your forehead in the process of acquiring the money, you get hit hard.
People who get money for nothing are not going to stop getting money for nothing just because you start taxing their gains. In contrast, people who work for their money might not bother putting in that extra hour if they know that they will lose a good portion to the tax man.
OK I give up. I think anyone who might happen upon this thread now has a clear idea about which part is based on experience and which part is based on ignorant speculation.
The R&D site has a massive base-station so that the phones would lower their transmission levels, thereby preventing the cancer of course.
Similarly, us in the telecoms industry have a conspiracy where we convince school boards that radiation is dangerous and get all wifi removed plus base stations placed far away. This ensures that the phones emit the high levels of cancer-inducing radiation needed to properly mind control the children.
At home those who are in on the conspiracy even place base stations right in their homes, in order to protect themselves! You probably have one of those deceptively-named "femtocells" too.
Radio waves don't just get absorbed when passing by some matter, they have to be of the right energy.
Water will absorb an extremely wide band. Contrary to popular belief, 2.5GHz is NOT a special resonant frequency for the water molecule, pretty much any cell phone band would work fine for microwave ovens. 2.5GHz was picked for engineering reasons, not out of physical necessity.
Are you seriously asking that question? If you are get the original owner of your user id to explain it to you.
Yes I am seriously asking that question. I need remote X for legacy apps approximately once a year. I need remote X for modern apps daily. Except modern apps do not work over remote X, so I use other protocols. Which again means that blaming Wayland for taking away the X ability to handle remote displays is disingenuous, because X does not handle remote displays either for anything more modern than xeyes.
Legacy apps are not interesting. They will by definition not start supporting other protocols, if they did, they would not be legacy. Therefore there is no point catering to them for new protocols such as Wayland. All that is needed for legacy applications is to give them an old-fashioned X server running in a window, just like OS X does. OS X handles remote X display of legacy X applications absolutely fine, and XWayland does it pretty much the same way. Wayland has feature parity with X for remote display already.
If it's in the same city it should be about that let alone on the same local network! Don't blame X when your latency is an order of magnitude higher than it should be.
Welcome to WLAN. I am not going to use a cable to get around the shortcomings of the X protocol. The desktop is dead, get over it.
True, rootless mode is the one advantage that X has over VNC.
Full integration is a bit of a stretch though. Only the basic X integration like simple clipboard and so on works. D-bus is not available through the X protocol, so proper GNOME integration is not possible. The forwarded applications are placed in their own little D-bus sandbox living on the remote machine, with no access to the D-bus that local apps use.