Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment: Light levels, not computer games (Score 3, Informative) 144

by gringer (#49307773) Attached to: Excess Time Indoors May Explain Rising Myopia Rates

For those who didn't pick up on the bit in the summary, this is not due to close work, it's most likely due to exposure to bright light:

But time engaged in indoor sports had no such protective association; and time outdoors did, whether children had played sports, attended picnics or simply read on the beach. And children who spent more time outside were not necessarily spending less time with books, screens and close work.... Close work might still have some effect, but what seemed to matter most was the eye's exposure to bright light.

If this is the case, then what we should do to reduce the myopia problem is to use brighter lights inside.

Comment: Re:Too many studies to keep track of? (Score 1) 112

by gringer (#49263091) Attached to: Scientific Study Finds There Are Too Many Scientific Studies

There are lots of studies on studies, and in general they are a good idea. Here's my take on that (from SoylentNews), slightly paraphrased to hopefully demonstrate why meta-studies can be good:

Keeping track of information is difficult, and journals generally don't like people to pepper their articles with too many citations. If the same information gets spread around, then the chance of citation drops for any particular article that contains that information. This is a problem, even with Watson-level recall, and even the very best papers will suffer from this issue.

Let's say there's a wonderful paper published in a journal that reviews a whole bunch of things. It survives for about 6 months with citations ramping up, but then someone discovers something new and interesting about one of those things. Then, people who would previously cite the big paper and therefore let others know about it, might decide that in their particular area, the new paper is a more appropriate citation.

About 6 months after that, the paper has hit its "peak citation rate", as the popularity of the paper is eroded in many different areas by the smaller, newer papers. Pick any one of those new papers, and you could easily say the earlier paper is better. However, pick any one of those many things, and you can probably find a better paper for the that particular area of study. Funding sources encourage this behaviour — being better than some previous paper, and fragmenting the research knowledge as much as possible.

People could read the single big paper and get a great overview, but over time they become more likely to know about the smaller papers which give excellent detail, but are very specific. Over time, the general knowledge of readers is reduced, and they lose track of related work outside their area of expertise.

Comment: Article progression (Score 1) 112

by gringer (#49263077) Attached to: Scientific Study Finds There Are Too Many Scientific Studies

For a change, this is something that appeared on SoylentNews before Slashdot. It has been interesting tracking this article through the social media sites that I frequent:

Reddit — Submitted Wed, Mar 11; 211 comments at the time of writing this comment

SoylentNews — Submitted Sunday, Mar 15; 16 comments at the time of writing this comment

Slashdot — Posted Monday, Mar 16; 30 comments at the time of writing this comment

Comment: Re:Science... Yah! (Score 1) 958

by gringer (#48967145) Attached to: Science's Biggest Failure: Everything About Diet and Fitness

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.

Comment: Re:Xscreensaver (Score 1) 375

by gringer (#48937009) Attached to: Why Screen Lockers On X11 Cannot Be Secure

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.

Comment: Re:Xscreensaver (Score 1) 375

by gringer (#48930447) Attached to: Why Screen Lockers On X11 Cannot Be Secure

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.

Comment: Xscreensaver (Score 5, Interesting) 375

by gringer (#48926109) Attached to: Why Screen Lockers On X11 Cannot Be Secure

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.

Yes, we will be going to OSI, Mars, and Pluto, but not necessarily in that order. -- Jeffrey Honig

Working...