Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment: Perl as an example of what, now? (Score 1) 581

by Foresto (#48420759) Attached to: Debian Votes Against Mandating Non-systemd Compatibility

Perl is hardly an example of improvement. Its widespread usage despite its fundamental flaws has given us a large body of software that is often entrenched and almost always a maintenance nightmare. I hope our OS distribution maintainers have the sense not to repeat that mistake with our init system.

Comment: Apply to be Whitelisted (Score 1) 405

by Foresto (#48383473) Attached to: Ask Slashdot: How To Unblock Email From My Comcast-Hosted Server?

Facing a similar problem a couple of years ago, I discovered that yahoo provides email filters not only for its webmail users, but also for several other companies. They have a procedure for requesting an exemption from their filters. It took a couple of tries, but I eventually got my server accepted. Here's the form:

http://help.yahoo.com/l/us/yah...

Comment: Not only in politics (Score 2) 282

by Foresto (#48341801) Attached to: When We Don't Like the Solution, We Deny the Problem

I've observed the same behavior in software development, particularly in the open source world. Some project maintainers are happy to have people helping by reporting the problems they find, while others will deny that a problem exists (and sometimes go as far as trying to discredit the reporter) if they don't happen to be affected/bothered by it. I guess inconvenient truths are hard for some people to accept.

Comment: Against it! It has no benefits. (Score 1) 613

by Foresto (#48291075) Attached to: Ask Slashdot: Where Do You Stand on Daylight Saving Time?

As far as I can tell, there has never been any statistically significant evidence that redefining time twice a year saves any energy, or has any other net benefit at all.

Meanwhile, it continually wastes the time of people who have to deal with the problems that it causes; moreso than ever since the world started depending on computers, and since international interactions have become common.

Just get rid of it, please. Forcibly playing games with people's clocks in the name of pretending that seasons don't exist is just stupid. Let businesses adopt winter hours if they want to align with daylight.

Comment: Frighteningly Dangerous (Score 1) 165

by Foresto (#48214641) Attached to: Proposed Penalty For UK Hackers Who "Damage National Security": Life

So it's basically carte blanche for anyone with a job in in politics, law enforcement, or prosecution to destroy the life of anyone they choose, based on nothing more than conjecture. Does anyone else find this frightening? Would the dangers of this idea be more obvious if the words "computer users" or "hackers" were replaced with the word "people"?

Comment: Alternatives (Score 1) 286

by Foresto (#48177167) Attached to: Ask Slashdot: Stop PulseAudio From Changing Sound Settings?

I ran into that same problem with Skype's latest release. Rather than giving Pulse a fourth chance to burn me, I decided it might be time to give WebRTC a try.

I'm so glad I did. OS-independent browser-to-browser video chat worked fine. I used Chromium on linux while my friend used Chrome on OSX. The latest Firefox release supposedly supports h.264, so it might work as well. Here are a couple of call set-up sites in case you'd like to try it for yourself:

https://opentokrtc.com/

https://vline.com/

Comment: Re:OpenID and OAuth (Score 1) 549

by Foresto (#48152925) Attached to: Password Security: Why the Horse Battery Staple Is Not Correct

So your answer is "trust the user".

No, my answer is that we are already trusting the user, a password authentication system cannot ever be more secure than that trust, and neither system can solve the problems upon which you based your assertion.

That's okay. I don't need to draw this out any further. I just wanted to unerstand how you came to your conclusion, and now I believe I do.

Comment: Re:OpenID and OAuth (Score 1) 549

by Foresto (#48147493) Attached to: Password Security: Why the Horse Battery Staple Is Not Correct

"Very few sites (even tiny web forums and such) are willing to trust arbitrary 3rd party."

Those sites wouldn't be trusting a third party; they would be trusting the user. Specifically, they would be trusting the user not to delegate his identity to an impostor-friendly provider, just as they are now trusting the user not to re-use his password on any site that will some day have a database leak or cleartext login form. Anyone who thinks his onsite auth buys him greater security than OpenID either has some magic way to force people into choosing unique passwords, or is sadly mistaken. I'll let you guess which is more likely. :)

I'm curious where you got the "very few" metric. Anecdotal evidence? A study with a large and diverse sample size? If you have some study results, I'd like to bookmark them. I guess it would just go to show that very few admins have a good understanding of overall security.

"There are other problems, like ensuring unique, non-spam/bot users, that can't be done with remote authentication"

Local password authentication can't solve those problems either. Bot and spam problems are solved by other means, like captchas and request rate throttles. Sane sites do this when an account is created, not every time a known-good user wants to log in. Some really careful sites take additional steps during login (like click/request/response timing), but those steps are invisible to the user and can be applied regardless of whether a local password is used.

Comment: OpenID and OAuth (Score 1) 549

by Foresto (#48136607) Attached to: Password Security: Why the Horse Battery Staple Is Not Correct

"We do, it's called Open ID, which is what Google leverages for their single-signon (not sure if FB is their own solution or not). It was a really popular thing about 5-10 years ago and got a ton of attention. I think even MS enabled it."

OpenID 2.0 accomplished something very cool: allowing a user to use any ID provider for authentication on any compatible web site, even if the two sites had never heard of one another. Unfortunately, it has two major problems:

  • It's too complex to easily implement. This became less of a problem once OpenID libraries like Janrain's emerged, but there are still subtle details left up to website developers to get right, and since many of them don't bother, a lot of sites that supposedly accept OpenID actually fail with some providers.
  • Perhaps more importantly, the URL-based IDs are not user-friendly enough for non-geeks. Several high-profile sites tried to solve this problem by replacing* the OpenID URL input box with a simple button for each well-known provider, but that meant limiting the user's choices of provider. At that point, the distinguishing feature of OpenID was lost, so lots of sites chose the simpler-to-implement OAuth 2 instead. The Login with Facebook service is one of them. Even Google eventually deprecated their OpenID service.

In my opinion, the issue of relying parties not trusting someone else as an identity provider was not such a big deal; certainly not enough to have killed OpenID. For every such distrustful site, there are dozens more simple web forums and the like that would be happy to get rid of their password database.

*stackexchange is a notable exception; they still offer the input box if you click a link.

Comment: Good. (Score 1) 774

by Foresto (#48096341) Attached to: Systemd Adding Its Own Console To Linux Systems

I think I'm glad to read this news, especially right now, because it might motivate someone to develop a better alternative.

I'd like to see something like this:

  • Starts services on demand based on dependencies, not based on order like sysvinit or events like upstart.
  • Has a minimal core that can easily run on its own, just to do the job of a standard init system.
  • Is easy to learn, configure, and understand.
  • Has good documentation.
  • Does not encourage application software to require it.
  • Does not encourage other system services to require it.
  • Works well on linux and non-linux unixes.
  • Is a lot less buggy than the stuff that I've seen from systemd's author.

Dead? No excuse for laying off work.

Working...