Comment Signature (Score 1) 86
Great, but could you please tell me how I can change my signature? I've looked in the Options and Account settings and can't find it anywhere.
Great, but could you please tell me how I can change my signature? I've looked in the Options and Account settings and can't find it anywhere.
Can I suggest SoylentNews?
Ah, thank you. Non-exercise activity thermogenesis. Now I have a research paper to explain my hypothesis about people heating themselves up to lose weight:
I've wondered if someone who wraps up in winter clothes every day is more likely to gain weight when calorie counting compared to someone who wears summer clothes every day. What I'd like to see is someone who does this and also monitors their body temperature, ambient temperature, and humidity throughout the day -- not a completely crazy idea given todays gadgets. If someone is cold, then their body will expend more energy to stay warm, and it will also expend a little energy to cool down when too hot.
To take this to the extreme, a person might live in a bomb calorimeter for the duration of testing, and make sure that all their excretions were calorified and included in the "calories used" column.
why are you letting jwz do your thinking for you?
An alternative, related question, why are you saying things without references?
I don't have a good knowledge of the intricacies of screen locking and controlling input devices, so I have to refer to others who I consider to share my general view point, but who appear to be more knowledgeable in a particular area. This is a very common approach in research, and separates out the people who have their own theories based purely on anecdotal evidence from the people who build on the theories and evidence of other research.
My observation is that almost every program has bugs, and the number of bugs increase (in a non-linear fashion) with the size of a project. Bugs in software that deals with authentication are particularly serious, because a bug may be exploitable to give someone privileges that they would otherwise not have (see toolkit discussion).
If you disagree, please address why security is something that should be handled by screensavers, instead of the display manager.
I don't feel that I need to do this, because it has already been addressed in the toolkit discussion. You're giving off the impression that you haven't actually read the toolkit discussion. Please provide some other evidence why the arguments put forward by JWZ are incorrect (preferably something other than "he is a pretentious idiot, so he's wrong"). Anyway, because you're giving this impression, I feel it necessary to post more of that discussion here:
So, you want xscreensaver to invoke the "unlock dialog" program and wait for a response. The unlocker would use a GUI toolkit, and would be linked against the various security libraries. Perhaps the way it would work is that it would print either "yes" or "no" on stdout, depending on whether a password was correctly entered. Were it to crash, the daemon would take that that to mean "no"...
In fact, this approach would actually reduce the number of libraries (and thus, lines of code) in the daemon itself, since the daemon would not need to link against things like PAM and crypto. That's a good thing.
So that doesn't sound hard so far, except that the xscreensaver daemon has the keyboard grabbed. It's pretty important that it hold that grab, because otherwise keystrokes tend to go "through" the xscreensaver window and reach random desktop windows underneath.
This [raises] the question of, how do the keystrokes get to the unlock dialog at all? That's a difficult question. Understanding how to do that right requires a lot of knowledge about X (which I have) but also probably a lot of knowledge about foreign-language input methods and screen readers and other accessibility-ware (which I do not have.)
In the current system, where the same process is the creator of both the screen-blanking window and the unlock dialog, this is not a problem: that process gets all the events it wants. But when they are in different processes, we need a way for the keyboard and mouse events to get to the process driving the unlock dialog. So you'd like to transfer the grabs from the xscreensaver daemon to the unlock dialog, and then transfer them back afterward. Unfortunately, there is no way to transfer grabs atomically in X.
Another possibility is for the xscreensaver daemon to keep its grabs, meaning that all keyboard and mouse events would go to it; but then for it to use XSendEvent() to generate synthetic events on the lock dialog window. That is, the xscreensaver daemon would read a KeyPress, and then would simulate an exact duplicate of that KeyPress on the lock dialog window.
[arguments against this: Applications can tell the difference between real and synthetic events, so might reject synthetic events as a security measure. Input methods need to be embedded in the dialog, rather than as a separate window]
In Summary
Making the xscreensaver unlock dialog securely use a toolkit is difficult, but possible, were a knowledgeable person to do the work. If the work were done well (by which I mean: clearly commented and documented, and with obvious attention paid to the security implications) I would be happy to incorporate those changes into the xscreensaver distribution.
Making the unlock dialog also be able to take advantage of accessibility tools is probably a lot harder. I don't know how much harder, because I'm not an accessibility expert. But anyone intending to implement that had better be both an expert on accessibility, and well versed in secure X11 programming, because the security implications of getting it wrong would be dire indeed.
He's already basically responded to this in the toolkit discussion. Anyone else could write a secure screen locker, but to do that properly you need to understand the code of all the libraries being used:
That's why I implemented the unlock dialog using only Xlib: not because I think Xlib is a good way to write user interfaces, but because I think this was the safest way. The amount of code in Xlib is very small, and has been extensively security audited. It is very unlikely that there are crashing bugs lurking in Xlib itself. The same cannot be said for larger, more featureful libraries. So, by making minimal use of Xlib (the dialog box is drawn using only the lowest level text-printing and rectangle-drawing routines) we can keep the code path short and auditable.
I am as close to certain as I can be that there is no action a user can take on their input devices that will cause the current Xlib-based lock dialog in xscreensaver to unlock. That's because it's a small amount of code that I have stared at and tested for a very long time. It is a small enough piece of code that I (believe I) know every possible path through it.
Introduce N layers of widget library, general text field handling, compose processing, input methods, I18N... and all bets are off. Who knows what bugs wait lurking in there; who knows which particular combinations of which libraries are a security-bug timebomb.
Let me put that another way:
The GTK and GNOME libraries have never been security-audited to the extent that their maintainers would be willing to make the claim, "under no circumstances will this library ever crash."
One can, within a reasonable doubt, make that claim about libc, or even about Xlib, but not about anything the size of GTK. It's just too big to be sure. This is not a criticism of GTK or GNOME or their authors: it's simply a truth about any piece of software of that size.
Jamie Zawinski has another explanation why screensavers on KDE can't be secure:
Like GNOME, KDE also decided to invent their own screen saver framework from scratch instead of simply using xscreensaver.
And Unity:
Guess what, they did it again! Ubuntu Unity's screen-locking framework is yet another rewrite, and it is completely broken, bug-ridden and insecure. At this time I don't have any information on how to turn it off and use xscreensaver instead. If you do, let me know.
He also has a writeup on toolkits, discussing why locking and unlocking is a hard problem, especially when accessibility features are required.
I recall an article a month or so ago about a town that had already done this, using high-bandwidth internet to determine energy use across the town. Unfortunately I can't remember the town or the company....
3D printing with wood? Oh, a bit like Laywood then.
The other composites are something I'm less familiar with, but I know that shapeways already has alumide as a printable medium.
And no one can tell who is correct:
You're confusing patent law with trademark law. Prior art is not particularly important for trademarks.
Can you please save your systemd frustrations for posting on soylentnews? We don't quite have enough of those yet.
I don't think you can put much blame about systemd on Linus. At least the first search I made on "linus torvalds systemd" was an article reporting a somewhat annoyed comment by Linus regarding the inability of systemd developers to fix their own bugs.
Hi, I'd like to hear a TCP joke
Hello, would you like to hear a TCP joke?
Yes, I'd like to hear a TCP joke
Okay, I'll tell you a TCP joke
Okay, I'm ready to hear a TCP joke
Okay, I'm about to send a TCP joke, that'll last for 10 seconds. It has two characters, it does not have a setting, it'll end with a punchline.
Okay, I'll get your TCP joke, that'll last for 10 seconds. It has two characters, it does not have a setting, it'll end with a punchline.
I'm sorry, your connection has timed out
On the other hand, I could successfully tell you an entire UDP joke, but you might not get it.
This is an important and worrying epidemic not because of how many infections or deaths there are now, but because of how many there will be by christmas, or in a year's time. Even with strict border controls, I expect that this is going to be all over the place in less than 3 years time, and very likely less if the virus mutates enough to have a greater contagious time for pre-symptomatic individuals. Containment for this virus is incredibly expensive, and spreading the virus around is incredibly cheap.
People just don't get non-linear progression and expansion. Ebola will hit the world hard before it is ready.
Come on, python's got its problems, but forcing you to lay out your program in a naturally readable way to compile isn't one of them.
I wouldn't mind python's indentation quirk so much if it didn't give me bugs when rewriting and transferring code, or if I could use braces (or something else) to indicate program flow. In short, changes in the control structure of the code can require indentation changes that cannot necessarily be determined by the editor:
A copy-paste of code from one place to another will only be easy to do in the case where the surrounding indentation is the same in both places.
When a particular bit of code needs to be surrounded in an IF statement (or a loop), it is necessary to manually re-do the indentation to indicate where the statement starts and stops.
If my editor decides that the default indentation is 2, while the code has a default indentation of 4, there's a chance I could inadvertently alter the program flow by re-indenting a line.
With other languages where structure is specified by non-whitespace, I can tell the editor to re-indent refactored code to accomodate new changes, taking a second or so instead of a minute or so (plus any time taken fixing bugs).
If you have a procedure with 10 parameters, you probably missed some.
