First bear in mind the attacker has local code execution. If they can put up a fake screengrabber, it's just a logout/reboot away from running a trojaned compositor (if you use Wayland), a trojaned screenlocker (if you use X) and on either system without even a reboot, a trojaned browser, terminal, ssh program and so on and so forth. So to say this is a serious flaw with X is hyperbole.

The next case is that you also claim Wayland is secure. Therefore X11 running on Wayland is secure. Therefore in that case X11 is being run in a secure manner. I claim that if that is the case, then X11 could very easily be secured, because it's eassy to see it in operation nowrunning in a way that the additional insecuritu doesn't break things.

I'm not really sure how creating yet another way for a "designated program" to monitor input events is supposed to address the problem that any X11 client can monitor keyboard events on any window in the absence of a grab, unless you intend to rewrite all existing software to grab the keyboard on receiving input focus, and force all the desktop environments to implement support for the extension and move their global keybindings into a specially designated client. At that point you might was well switch to a system designed for secure I/O from day oneâ"like Wayland.

OK, I'm lightly lost so I'm going to swing back to the original point.

First there's the one about server grabs which prevent other windows from opening. Well, you could easily have a protocol extension that allows only one connected client to bring up windows anyway. The continuation of the grab could either be faked to the grabber, or killed outright (the latter feature---killing grabs---was removed from Xorg by the wayland people because they decided we didn't need it!). Let's say it's first come, first serve, so that the first client to request this feature is the only one to get it. Or the screenlocker could get that command. This requires the WM and screenlocker to be run on boot before a trojan, but as I pointed out, if the system is that deeply trojanned anyway, then this is all pointless.

That requires some rewriting to whichever screenlockers you want to add the feature to, hardly a major undertaking since there's about 3 in common use and a few, more obscure, ones.

The other problem---a designated screen lock key combo. Well, if the screen locker has a passive grab on ctrl-alt-delete, then the fake screenlocker can't grab that, so that already works.

It's easy to implement the insecure X11 model on top of a secure system. The reverse is much more difficult.

Why? Why not have exactly the same security model? You haven't explained, only asserted, that your chosen security feature couldn't be easily available under X.

In fact when it comes to locking things down, there are things like the X security protocol, which blocks untrusted programs from executing various protocol commands. This already exists and could (I haven't checked if it does) easily block things like receiving events from a window on another connection, reparenting or redirecting a window on another connection, diddling with the global keymap and so on.

Anyway if there's unsanboxed local code execution, you're basically screwed on any system.

You're not going to get any of my data that way, which is what is actually important.

I'm not sure I follow. Surely if I had unlocked access to your phone, I could simply read whatever data was on there? Also, can you install free apps without an additional password? If so what stops me installing a keyboard app trojan?

Honest question: I don't own an iPhone. If it stops those kind of attacks it would be great to know how.

What exactly would you propose to add? This isn't a matter of implementing new functionality, but rather removing fundamental misfeatures. Any change to address this issue is going to end up breaking existing applications which depend on the original input behavior.

Oh how about a new protocol extension that allows one designated program to receive all keyboard inputs regardless of any other grabs. The X11 server can keep on pretending that the other grabbers still have such a grab.

Look: X11 works on Windows even though windows can apparently REALLY gab the keyboard. X11 will we are told work on Wayland too despite the fact that wayland can apparently REALLY grab they keyboard. Do you really think it couldn't be extended to do that itself?

Which could be a good argument for replacing X. It is rather old technology, perhaps it is time to update it to something newer, rather than clinging to it and claiming it is all one needs.

Or how about adding a protocol extension to deal with this security problem as has been done a number of times in the past for authentication. I don't understand why X11 seems to get special treatment here.

Program has security flaw. Response "has it been patched yet"

X11 has security flaw: we can't possibly patch it we must discard everything and start again.

There's certainly some things wrong with X11, but this is one which could be solved easily. It could, for example, be done by having a "kill all grabs" command which is available to the window manager.

Uh.

Why can't I have my screen locker have a passive grab on Ctrl+Alt+Delete or shift+altgr+control+` or whatever, using XGrabKey. That way if someone else installs a screenlock faker then I'll know because it won't respond to the magic key presses.

The thing is on Windows it never worked as well as it ought to. The reason is that if the screen said something like:

"pls entar u r passwordz to login"
[ password box ]
[OK]

"pls wate wile redirecting to http://scamsite.ru/yourbank"

"Pls entar u r bank passwrd thx"

an appalingly large number of people would have dilligently followed those steps. the ctrl+alt+delete thing was fine but required more knowledge than 99.9% of users had.

Oh and the active grab thing: if you ever hear a wayland dev tout that as a problem, please kick them in the nuts because it XFree86 USED to have a feature for killing grabs from a keystroke, until the fuckers who went on to develop Wayland decided we didn't really need it because "it would only be needed if a program is buggy". Well, no fucking shit hotshot.

Why is this considered acceptable? Get physical access to my iPhone (for example - Android is probably the same?), good luck getting in.

Huh? This exploit only works if someone has already had access to your unlocked computer long enough to load and run malicious code. It's not like oyu can plonk down someone at a computer wit ha locked screen and have them hack in by being clever.

And if I had access to your unlocked iPhone, could I not root it or whatever the iPhone cracking is called and install a fake screenlocker too? Or hell, install a custom keyboard app which looks like the normal one but saves all passwords and sends them to the cloud. I might not even need to root it to do that.

Well, yes.

However, that only works if the attacker already has arbitrary local code execution. If they can do that then they can trojan every single program, by diddling with the PATH environment variable and/or pissing with LD_PRELOAD.

Basically yes, it's a hole but one that only kicks in if you're fucked 6 ways to Sunday already.

Or if you've done xhost+ and disabled your firewall. But that hasn't been the default in years.

What happened?

I'm guessing that people got fed up with churn and started to realise that change for its own sake is annoying. Getting irritated at having to get used to a new system AGAIN that does things worse in many cases is not unreasonable. Being fed up with churn is not the same as fearing change.

Personally, I like to see "change" actually make things better, because if it doesn't then why bother with the change? And if it makes things worse, then WTF?

A lot is just uninspiring and meh. Going from flat to bevelled to bulbousd and back to flat (hello Athena!) user interface elements is just a huge meh. I mean sure, now they're coloured and antialiased and with nice fonts and whetever, but I really can't feel myself getting excited about "flat" design. Actually, personally I think it's a bit of a usability regression becase it's harder to explain to people which the active user interface elements are.

Change where it's an improvement I like. I like large, high res screens. I like running a modern kernel with all the new power saving features and better, newer filesystems and so on and so forth. I tend to run recentl builds of tools I like like vim and mplayer because the changes make them better than the old version. I keep promising myself I'll finally switch from Xterm to Terminology, but I can't get some of the features to work properly at the moment.

All those things, all those changes have made stuff better. On the other hand, I still run FVWM2. I've tried more modern things, but they all seem to make things worse in interesting ways. I've still adopted some changes, however which make it more modern.

I think there are quite a few people here with similar opinions to me. Another example: the reason that tablet stuff coming to laptops is bad is because a lot of the UI stuff is designed around single, non cooperating, full screen apps. I don't want that, not because I fear change, it's because I changed AWAY from it in the 90s and I have no desire to go back to the bad old days. I remember what it was like all too well (and my phone just keeps on reminding me). What I fear is being dragged back to something I know from experience is inferior.

Nope: there still needs to be a sliding contact between the wheel and a fixed cable somewhere.

Anyway, sliding contacts work just fine. See, e.g. trains with 3rd rail, 4th rail, pantograph and mixed mode trains and trolley busses and even some whacky covered contact trams.

The latter are particularly interesting. Some cities want an electric tram installed but don't want to have overhead cables or exposed foot level contacts. So, there are studs in the ground and they only switch on after the tram has made contact. The old systems were unreliable, but with modern arc-free power semiconductors, they work well and no arcing.

Indeed, and I think it's reasonable to call out the posters who say "oh they're idiots, why don't they just..." and so on and so forth.

However, it IS fun to speculate with a bunch of reasonably knowledgable people on mechanisms for going beyond what is currently technically feasible.

The powered lift with a rack and pinion is an interesting idea. I'm struggling to work out how much additional power it would take. With a short lift, you can discount the weight of the cable, and so you can have the lift counterbalanced easily and the motor must lift the ddifference between the two sides plus the friction.

With a long cable, the weight to be lifted changes with height: the further down the lift goes, the higher the weight. If you counterbalance with the same mechanism, then the balance will only be equal in the middle. At the bottom, you need to lift the entire weight of the cable, which in a high lift can be more than the lift.

At that point, having a motor which can lift the entire lift minus the cable isn't infeasible. Of course, you have to lift the motor too. And then there's the problem of power delivery. Maybe something like a train pickup could be adapted to work.

The power will be enormous, but one could offset it at a building scale using energy recovery, either have lifts run in oppsition where the descending one powers the rising one, or have the lifts all connected into a busbar which has some large piece of rotating flywheel storage to absorb or emit energy as required.

Apparently there are a few companies working on cableless elevators for exactly these reasons. Some have linear motors instead of a rack and pinion.

My son was reading for content (Pokemon game guides) before he was reading for pleasure

Er, how is that not for pleasure?

Besides, my point still stands. No one says you must learn to read so you can understand voter registration forms or whatever.

Apparently "many eyes" were not reading that bit of code.

Will you please actually read the quote rather than quoting an inorrect interpretation. The quote is:

"given enough eyeballs, all bugs are shallow"

It means that once a bug is found, it is shallow, i.e. quick and easy to solve for someone. It doesn't and never did mean that all bugs will be found.

Oh gee, and here I thought it meant merge basic blocks.

Nope. As you pointed out yourself it's only a hint to the compiler whether to actually inline or not. When it is not inlined, the symbol has to be weak, because the function may be exported in may object files: which ever object files have a corresponding source file which includes the function.

Therefore all inline really means is "export as a weak symbol".

Do you know _anything_ how C++ compilers even work??

Yes, which is why I know that thing about weak symbols. You apparently do not.

You love to constantly make incorrect and incomplete assumptions.

Well no.

2. Gee, why do things like _Profiling_ exist. The *compiler* doesn't have access to *run-time* performance. The optimizer is dealing with a _subset_ of data. It doesn't know the "function temperature"

Compiling (under gcc) with -fprofile-arcs, running the program generates that information. Recompiling with -fpbranch-probabilities then tells the optimizer to use the run-time information. That said, I don't think function temperature has much to to with whether to inline or not.

1. I want to write ONE directive not clutter my code up with hacks PER compiler. _Why_ do standards exist ? To make everyone's live _easier_.

And anyway, you still ignored my point. The committee have standardised function attributes, which is 95% of the way towards having what you want. Write a proposal to add force_inline as a standard attribute.

So Verizon accepted a fine of $5,000,000. For Verizon, I call that a success. Given their size nothing at all is going to cost them less than 5 million. There is no way in hell that investigations into rural phone problems would have cost less.

This is just the cost of doing business, and it's certainly more profitable to break the law and pay the fine than it is to do what they are supposed to do.

Until the fines are set to a level to remove all profit and THEN put a punishment on top, large business will continue to flout the law because it's more profitable.

Do you _actually_ use different compiles on different platforms at all ????

Yep.

'inline' is only a hint

Inline specifically means "export this as a weak symbol".

I can chose between Microsoft's __inline or GCC god-awful __attribute__((always_inline)) syntax.

Yes, but why are you trying to do that? You're fighting the optimizer and you're almost certain to lose.

Nonetheless you're ignoring the other part of the reply that the C++ committe has in fact standardised a way of specifying attributes. Why don't you submit a paper specifying some always inline attribute?

You're constantly complaining about "breaking things." Gee, if only there was a way to migrate, mitigate, and deploy change ...

You wishing something to be the case dosen't make it happen. Unlike your silly car analogy, there is no government body who will arrest and detain anyone using C++98 after some flag day. As a result it will cause fragmentation just like Python 3.

Gee, why does Microsoft provide a _specific_ number for _each_ warning ???

Uh? Again, there is no language where error messages are standardised. The fact that MS provides numbers for each one is a total red herring. Like I said, complaining that the C++ committee have their heads up their arses because they're not standardising something that no other language spec ever standardised is basically idiotic.

But now you've wandered into bizarro world with warnings. So what would the procedure be? The warnings which a compiler is capable of emitting depend quite strongly on the code analaysis part which is in part dependent on the optimizer. There is no way to get GCC, LLVM, VS and ICC to have exactly the same set of warnings. And then what would the procedure be for new warning?

Seriously, the standards committee cannot make something happen by magic. If they try to do something that no one is going to implement then it's a pointless and destructive waste of time. They learned their lesson very well with exported templates. All sorts of people begged and whined for it, so they did it. They didn't listen to the howls of anguish from the compiler writers. All that happened was a dead stub of a standard which almost no compilers ever supported.

This is a solution in search of a problem.

So you're saying that the C++ commitee shouldn't be reading and considering every proposal that is submitted according to the correct procedures? So how should they filter them? Ask you and see if you give the thumbs up?

1. Completely failing to understand _practical_ matters.

Says the person who believes that by magic the C++ committee can make everyone switch to a new, incompatible language and avoid fragmentation! That's about the biggest practical matter and you claim outright that it doesn't exist. Then you rather hilariously accuse me of not understanding the practicalities.

OK, smart-ass, how would you force everyone to switch to a future non-backwards compatible version?

2. Continue to make excuses for why their tools are crap.

Tools are crap for reasons you haven't mentioned: namely it's sodding hard to parse C++. Because of (1) the committee can't fix that. But again, the OP complained that the "committee have their heads up their asses", which is a foolish and ignorant statement. There hasn't ever been a language standard which specifies the kind of tooling he was asking for.

And tools have nothing to do with the language standard.

3. And then post blatantly false information that gets modded up to Insightful without a clue.

Except nothing I said was false.