Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Re:Mailing lists (Score 1) 139 139

Unfortunately, DMARC breaks even mailing-lists which do not tamper with the contents of the messages at all. The reason is simple: SPF. Rewriting envelope senders is the proper way of forwarding mail since ages.

If you want to have proper integrity checks of e-mail messages, use PGP, not DMARC.

Comment: Re:Mailing lists (Score 2) 139 139

What they mention is not a list of solutions, but a list of silly work-arounds, which break well-established semantics of e-mail headers. Falsifying information about the author of the message (that is, the From header) for the sole sake of making the message compatible with DKIM is broken.

Comment: Re:Some Sense Restored? (Score 2) 522 522

A traditional init script is just a shell script, including almost invariably a couple of nasty race conditions and other subtle bugs. Starting and stopping a daemon safely is close to impossible in shell. I am not a huge fan of systemd, but init scripts written in shell are a nightmare.

Comment: Re:NSA (Score 1) 127 127

I think part of the rationale is that a self-signed certificate very well might be a sign that you're the victim of a man-in-the-middle attack, and it needs to be treated as a serious potential threat.

This sounds good in theory, but the reality is that self-signed certificates (or those signed by an authority your browser does not recognize) are several orders of magnitude more common than MiTM attacks.

Otherwise, I agree that a big part of the problem is unusable UI for managing certificates in almost all existing browsers.

Comment: Re:NSA (Score 1) 127 127

I expect the browser to clearly inform the user whether the connection is safe (HTTPS with a verified certificate) or unsafe (either plain HTTP, or HTTPS with an unknown certificate). I also expect the user to check that a connection to his bank is reported as safe. If you are interested in preventing attacks against careless users, the browser might also notify the user that a site previously known to have a safe connection, no longer has one. However, I do not think this is of much help: many users just enter the domain name of their bank and rely on the bank to redirect the HTTP version to the HTTPS one, which is where a MiTM attacker can always succeed. (An interesting special case is invalid certificates: expired ones, or certificates issued for a different domain. Here, a big fat warning could be appropriate.)

Comment: Re:NSA (Score 5, Insightful) 127 127

Is "as bad as no encryption" a reason for yelling on the user and presenting it like the worst security problem ever? Even if I accept the premise that it is as bad as no encryption, the obvious conclusion is that the browser should present it the same as no encryption.

Actually, it is not as bad. It still keeps you safe from passive attacks (like your ISP collecting all data for a three-letter agency, which analyses them later).

Comment: Re:IBM (Score 1) 367 367

Using threads with locks and other traditional synchronization primitives is a walk across a minefield. More than 90% of multi-threaded programs I've ever seen are full of race conditions and other subtle bugs, which are not easily visible, but which make the program unstable on the long term (it is not unusual that a program suddenly deadlocks after running for several months). If you really want to write something parallel, use a language which provides a better abstraction, one of the possibilities is transactional memory.

Comment: Re:Thoughts from a core GNOME 1.x and 2.x develope (Score 3, Insightful) 432 432

The core of the problem is that GNOME developers have the habit of releasing as 2.0 or 3.0 something, which is of beta quality at best. It's quite possible that GNOME 3 contains some great ideas, but trying to attract users to software, which will need a year or two more to reach usability of the previous version, is not going to win anybody's sympathies. Exactly this has already happened with the release of GNOME 2.0: its usability was nowhere near that of GNOME 1.x, but still, it was presented as a replacement of 1.x. The users were rightfully complaining. One would have hoped that GNOME developers have learned something from that fiasco...

As of culture resistant to changes: For most people, the computer is a tool. And as with many complex tools, it takes time (sometimes years) to learn how to use them in the most efficient way. The learned experience is very valuable, but a part of it is necessarily lost when the tool suddenly starts behaving differently (people are not used to their screwdrivers changing shape overnight). Sure, changes are necessary for progress, but you should not ignore that changes come with a high cost to the users and radical changes of basic concepts even more so. Changing details is usually fine, removing functionality is worse, and radical changes of established products should be done only in cases, where the benefit is an order of magnitude larger than the loss. GNOME developers seem to ignore this fact of life for years.

Comment: Re:Slashdot has gone batsh*t crazy (Score 1) 190 190

UEFI Secure Boot solves a security problem which, while being real, is completely marginal in real world. The extra complexity with key management is simply not worth the gain. There is a zillion of places where you can improve real security of systems at much smaller cost.

What is now proved was once only imagin'd. -- William Blake

Working...