Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:NSA (Score 1) 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

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

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

by tajribah (#41180421) Attached to: Polish Researcher: Oracle Knew For Months About Java Zero-Day
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

by tajribah (#41043755) Attached to: GNOME: Possible Recovery Strategies

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.

People will buy anything that's one to a customer.

Working...