Follow Slashdot stories on Twitter

 



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

Comment: Re:HOME ownership is key (Score 1) 579 579

You have to be able to float that much money to wait for the rebate, correct?

Not if you lease. If you lease, it's the lessor that gets the rebate, so when they calculate the financing they just take it off the top. The federal credit, anyway. This is one of several reasons why more EVs are leased than purchased.

Comment: Re:The reason is more simple (Score 2) 579 579

He also says he had to install a 240V socket it in his garage because apparently though you can charge it on 120V in a pinch, apparently it can cause damage to the batteries. That's according to Nissan.

This is incorrect. Charging on 120V doesn't do any damage to the batteries, in fact it's probably a little bit better for them. The problem with level 1 charging is that it's slow. Assuming the LEAF's battery is empty it takes about 21 hours to charge it to full on the 120V adapter included with the car.

I actually charged my car regularly on 120V and it wasn't as bad as you might think -- as long as I only needed to make one trip into town per day (from my house to the city is about a 40-mile round trip). The car was almost always fully-charged by morning, but if I went somewhere in the morning and came back home, there was no possibility of making a second trip in the afternoon or evening. Not without stopping off at the level 3 charger in town, anyway. Which I did from time to time -- it's free, and recharges the car from empty in about an hour, but it means having to kill an hour, and there isn't much of interest within walking distance of the charger.

So, I installed a 220V "level 2" charger. With it, the car recharges from empty in a little under four hours. In practice, that means that when I pull into the garage and plug in, it's generally full again in a couple of hours. Most of the time the flexibility that provides doesn't matter, but sometimes it's very handy. The level 2 charger cost me about $400. Was it worth it? Maybe, maybe not.

Comment: Passwords are not the only way to authenticate (Score 1) 74 74

Both of you are wrong and so is Dustin Kirkland (whoever he is). The core of your error is in this statement:

Only secrets can be used as token for authentication.

That sentence is true, as stated, but only because it includes the word "token". Yes if you're using secret tokens for authentication, then the tokens must be secret. But exchanging secrets (or proof of possession of secrets, which is what most cryptographic authentication protocols do) is not the only way to do authentication. Not by a long shot. In fact, humans hardly ever use secrets for authentication.

How do you identify and authenticate your mom? Do you ask her for a secret password? Of course not. You use the same tools for both identifying and authenticating her, and those tools are a set of biometric markers. The same set of tools are also used in high security situations. Back when I was a security guard in the Air Force, I was trained that personal recognition is the very best form of authentication. Not only is it not necessary to check the badge of an individual you know personally, badge-checking is inferior to personal recognition for authentication (note that badge-checking may still be important for authorization, verifying that the person who has been identified and authenticated actually has permission to enter. Thus I was trained to always check the access control list before allowing someone near nuclear weapons).

With respect to user authentication in electronic contexts we generally use secrets because computers don't (or at least haven't) had the ability to use the sorts of biometric authentication that humans use quite effectively. But, when we equip them with biometric sensors, they can.

HOWEVER, this does not mean that biometrics are useful for authentication in all circumstances.

Secret-based authentication has the advantage that -- assuming the secret has sufficient entropy and can be assumed not to have leaked nor been intercepted and cannot be rerouted (note that that's a pretty long list of criteria, some of which are hard to establish) -- you don't have to worry about the possibility that the authentication could be spoofed. An attacker who doesn't know the secret can't fake knowing the secret.

Biometrics, though, are not secrets. They are public knowledge. This means that an attacker must be expected to have access to copies of our fingerprints or faces. The biometric authentication process is different, though. It does not rely on secrecy of the authenticator, but instead on non-replayability. If we can be certain that (for example) the fingerprint placed on the scanner belongs to the person we wish to authenticate, and that the stored template we match against belongs to the person we wish to authenticate, then we can perform a good authentication. The fact that the fingerprint is not secret does not matter.

Where biometrics fail is if (a) we can't be certain that the livescan data acquired from the sensor belongs to the person trying to authenticate or (b) the stored template belongs to the person we wish to authenticate. Part (a) is particularly difficult to validate in many contexts because faking the input isn't necessarily hard to do, and in some cases an attacker can even bypass the sensor entirely and simply inject a digital copy.

This doesn't mean biometrics are worthless, it just means they're only useful in certain contexts. And, again, their utility for authentication has nothing to do with their secrecy. And rotation is likewise irrelevant and silly to discuss. You need to rotate secrets because you can't be certain they have stayed secret and because if they have low-ish entropy they may have been brute forced. None of that applies to biometrics because they're not secrets and their utility as authenticators does not depend on secrecy.

Can we please kill this incorrect meme about biometrics as identifiers, not authenticators? They can be either, or both, and are used as both, by billions of people, every day, with high effectiveness and reliability. Whether or not they provide security depends on the context.

With respect to credit card payments, fingerprint and facial recognition biometrics are pretty reasonable tools. This is especially true if the sensors are provided by the retailer, and the consumer is providing a traditional electronic authentication (cryptographic challenge-response) with their smartphone or smart card. It's not quite as good if the smartphone is also providing the fingerprint scanner and camera, because in the event of an attempted fraudulent transaction that means the attacker is in control of those components.

But you also have to consider the model that is being replaced. Is fingerprint plus face recognition better than a signature which is theoretically matched by a non-expert human, but in practice never checked at all? Absolutely. Is it better than a four-digit PIN? That's debatable, but it's at least in the same ballpark.

Comment: Re:Most of their apps are annoying anyway (Score 1) 109 109

I tried Inbox, but wasn't impressed. It strips so much of gmail away that it is basically "Gmail for beginners". You want filters, labels, etc, then it is worthless.

Actually, Inbox is Gmail for power users, for people who have massive volumes of e-mail to manage. It takes a little bit of work to figure it out and set it up, but once you have, it's awesome. There are some features it lacks, like complex filters (simple filters are very easy to set up; you just move a message to a label and Inbox asks if you want to always do that. Click "yes" and you have a new filter rule), vacation auto-responder and the like, but you can always use the Gmail UI when you need to set stuff like that up.

The Inbox features that that make it great for heavy e-mail users are:

Snooze.

Many people use their e-mail inbox at least partially as a task list, especially their work e-mail. This results in having to keep e-mails that for you can't work on yet sitting in your inbox, cluttering it up and making it harder to process new e-mail. When you snooze an e-mail, it goes away until some point in the future. You can pick a date and time, or even a location (requires using the Inbox app on your mobile device). Heavy application of snooze with well-chosen times/locations lets you clear all of the stuff you can't do yet out of the way, knowing it will come back later when you can handle it.

Bundles.

Bundles are just Gmail labels, but with an additional setting that tells Inbox to group them in the inbox. This is fantastic for high-volume mailing lists. With Gmail you can get almost the same effect by setting a filter to apply a label and skip the inbox, but then you have to remember to actually go look at the label from time to time. With bundles, you get the same grouping effect but the bundles show up in your inbox so you don't forget to go look. The reason that grouping (by whichever mechanism) is useful is because when you have large volumes of email, most of which you don't actually need to read, it's much faster to scan through a list of subject lines and evaluate what's important and what isn't when you already know the context.

My process for plowing through a busy mailing list is to scan the subject lines and click/tap the "pin" icon on the few that are interesting, then "sweep" the rest. A single click or gesture archives all unpinned items in a bundle. Then I handle (or snooze until I can handle) the pinned items.

I also have a bundle (label) called "Me" that is applied by a filter that looks for my name or username in the To line or the body of the message. This helps me to be sure that I notice e-mails where people are mentioning me or asking me questions. It's the first bundle I look for every time I check my e-mail. Similarly, I have a bundle that extracts e-mails that reference my project's name. That's the second bundle I look at. Other high priority bundles are e-mails from the code review system and e-mails from the bug tracker.

Obviously there are many e-mails that mention both my project and me. That's fine; bundles are labels not folders, and it's perfectly reasonable for an e-mail to be in more than one of them. When I archive a message in one bundle, it disappears from the others. So, often I'll look at Inbox and see the "Me", project, code review and bug tracker bundles displayed, but by the time I've processed everything in the "Me" bundle, the other three have disappeared.

Delayed Bundles.

I think this vies with snooze as the killer feature of Inbox. By default, a bundle appears in the inbox whenever you receive new mail with that label. But there's lots of stuff, at least in my inbox, that I don't need to see immediately. Having low-priority stuff displayed instantly distracts me from my work, or obscures truly urgent e-mail. Also, it's more efficient to handle low-priority e-mail in bulk. So, you can specify that a bundle should only appear once per day, or once per week. Inbox will accumulate e-mail in delayed bundles and only show the bundle at the specified time.

When I start work in the morning I have a dozen or so bundles containing low-priority e-mail. I can quickly scan each of them, pinning the items I care about and sweeping the rest. I have a few bundles for purely informational mailing lists which are set to display once per week, so I only see them on Monday morning.

I'd like a little more granularity on this feature. Specifically, I'd really like to be able to set some bundles to show, say, every three hours. Then I'd only allow the highest-priority bundles to show immediately, giving me larger blocks of uninterrupted time but with the knowledge that I'll still get notified of truly urgent stuff immediately.

Consistent Interface

It took me a while to realize just how valuable this is, but it's really great that the mobile and web UIs for Inbox are virtually identical. I don't have to have two different flows for handling e-mail on mobile vs desktop. The mobile UI is a tiny bit better because of the gestures a touchscreen interface can provide, but my process for using it is the same.

One common complaint about Inbox vs Gmail is that Gmail's more compact; you can fit a lot more stuff on the screen with the Gmail UI. I find that isn't a problem, because the Inbox workflow mostly eliminates the need to scan through a big list of messages visually, looking for something in particular. The need to do that arises mostly (for me, anyway) when I'm keeping a lot of stuff hanging around in my inbox. With Inbox, I don't do that. I snooze it or I archive it, so my inbox is empty nearly all the time. If I need to find something that I've snoozed or archived, I search for it.

Bottom line: If you're a heavy user of Gmail, you should really take a good look at Inbox. Odds are you'll never go back.

Comment: Re:I have another way (Score 1) 480 480

Microsoft has two solutions; only share passwords using their Wi-Fi Sense service, or by adding "_optout" to your SSID.

Or, just don't use windows 10. I think I may have found the answer there.

Also, don't give your SSID to anyone who does or might in the future use Windows 10, or have a Windows phone.

Comment: Re:Project Management or Business Analyst (Score 3, Interesting) 246 246

+1

Not to be sexist, but most women prefer jobs that include more interaction with people and less time spent in solo problem solving, so it's not terribly surprising that she does't love coding. This isn't to say there aren't women who really like coding, or even introverted women who find working with people all day to be unpleasant. There are all kinds... but on average my observation is that women prefer more human interaction.

So, assuming that your wife falls into that category, there are lots of roles in and around software development that are more people-focused. Project management requires an additional set of skills, both people skills and management skills, but it's eminently learnable, and having a technical background is very valuable -- as long as it doesn't cause her to second-guess what the developers are telling her (always a risk with PMs, and even more with those whose technical background is shallower than they think it is. There's a tendency to assume that everything they don't know how to do is easy.)

Business Analyst is another good one. It, again, requires some additional skills she probably doesn't have but can learn. Industry knowledge tends to be important, but most companies are okay with analysts learning that context on the job. She also needs to learn how to gather and document requirements. A technical background is useful there because good requirements need quite a bit more precision than most non-technical people are used to. There's also a risk; formerly-technical BAs have a tendency to overspecify. An important skill for this role which isn't so easy to learn is writing. Good BAs are excellent writers, able to concisely and accurately boil complex issues down to simple statements.

Another option that might be excellent if she can swing it is Systems or Application Architect. Companies generally want experienced, senior developers to move into these roles, but smart but less-experienced people can do it as well. Architects take the business requirements and convert them into high-level technical plans/architectures. Architects tend to spend less time interacting with people than PMs or BAs, but still quite a bit since they provide the primary interface between the technical and business teams. Architects need to have good technical skills and good "taste", meaning a good feel for what sorts of structures are easy to build, easy to maintain and flexible, and for how to intelligently trade those issues off. They also need to be good at translating technical issues into language the business people can understand. Honestly I expect that your wife probably doesn't have the depth of experience needed to make a good architect, but I thought I'd throw it out.

Another that might be good if she's a good writer and enjoys writing is technical writing. Good tech writers have greater need for writing skill than they do technical skill, but the latter is very valuable because it enables them to more quickly and accurately understand the information that needs to be documented.

In smaller companies a lot of these roles get mixed and combined with other business roles, so another good option is to look for a position that isn't necessarily directly related to software development, but could benefit from having a deeply IT-literate person.

Finally, the option that I've long thought I'd take if I ever got tired of writing code is the law. It's a lot of additional training, but I think there is a deep and growing need for attorneys who understand technology. This is especially true in the areas of patent and copyright law, but I think it applies in many areas. Of course, the law may not have any attraction whatsoever for your wife.

Whatever, I'd really encourage her to take the time to figure out what she wants to do, and do that, rather than settling for something she doesn't really like. We so much of our lives working that it's really a waste to spend it doing something we don't like.

Comment: Re:The founding documents present a path... (Score 1) 161 161

The electorate fully agrees with him.

This is completely untrue. The electorate is pretty divided, and whether you can find a majority depends which poll you look at, and which week. The fact is that there is a significant part of the electorate that thinks bulk surveillance is fine because they have nothing to hide and it keeps us safe. That they're wrong on both counts doesn't change their opinion, or their votes

Congress mostly agrees with him.

And yet they passed the USA Freedom Act which, although better than the PATRIOT Act, still authorizes way too much surveillance. And in the process they failed to do anything to curtail article 702 of the FISA, which is the basis for the FISA court's ruling -- as was completely predictable before passage of USA Freedom. The argument is that while article 702 authorizes only surveillance of foreign people, the court considers it perfectly reasonable for the NSA to hoover up ALL the data and then figure out later what they can and cannot look at. This all comes back to the NSA's choice to define "collect" as "look at", since the law hadn't defined the term.

Congress had a perfect opportunity to define "collect" as "collect", and chose not to.

Yeah, we have a problem here. And the "democratically elected government" ain't it.

The problem is fundamentally the electorate, which isn't sufficiently convinced that bulk data collection is a bad thing. If 80% of the voters wanted it shut down, enough to make it a major election issue, it would be shut down. But as is Congress knows that with a slim majority (at best) concerned about data collection, if they shut it down and then Something Bad happened the voters would turn on them like a rabid dog.

The system isn't perfect, but it is basically working as intended. We just need to convince more of our fellow Americans that surveillance is bad.

Comment: Re:Apples and oranges (Score 2) 107 107

... it's just a little more than 1% the size of OpenSSL...Notably, s2n does not provide all the additional cryptographic functions that OpenSSL provides in libcrypto, it only provides the SSL/TLS functions....

So then, aren't size comparisons between OpenSSL and s2n at best useless, and at worst intentionally misleading?

No, but this particular comparison is. Besides all of the stuff s2n doesn't provide, s2n actually uses OpenSSL's libcrypto to provide the implementations of all of its crypto algorithm. A useful comparison could be made between OpenSSL's TLS layer and s2n, with some caveats listing the TLS features s2n doesn't provide.

Note that none of this means that s2n doesn't have value. If you don't need the other OpenSSL features, it's a lot less code to audit.

Comment: Re:Soooo... (Score 5, Informative) 44 44

Like most of the up-voted posters here, I think you're missing the point. This new service isn't a Google Code replacement or a Github competitor. It's an add-on for cloud-based hosting, so people who are hosting systems on Google App Engine or Compute Engine can keep their source there as well, with nice tools for working with the code online, managing releases and even live debugging... if there's a problem with your running app you can debug it instantly. The system snapshots the live system so it's not interrupted and then gives you an online debugger so you can examine the state, step through the code, etc.

It's a value-added feature on a paid cloud hosting service, not a place to host your latest open source project. That's what Github is for.

Comment: Re:Less suspect than the others (Score 5, Interesting) 78 78

But one of the vulnerabilities I've pointed out recently to proxy maintainers is that it's become quite commonplace to host SSL based traffic on an external router or load balancer, and carry it entirely unencrypted between that load balancer and the local server. It often eases maintenance of SSL keys and allows far less expensive, small servers to handle the actual traffic and allows the cost of robust SSL services to be shared more effectively.

Google's encryption is end-to-end. It's also not SSL-based, but instead much simpler and more robust (and more efficient), though there's nothing proprietary or custom about the encryption ciphers or protocols used (Google employs lots of cryptographers who would quickly stomp on any questionable designs). I work for Google and used to do stuff related to internal network encryption though I worked on a different aspect of it, focused on securing payments data (credit card numbers, etc.).

I think it would be awesome if Google were to publish the details of its security infrastructure, which is dramatically better than anything I saw in my 15 years as a security consultant, but AFAIK that hasn't been done so I have to keep my comments vague and high-level.

I'll also point out, since I know it has been mentioned publicly, that Google didn't actually start doing all of the link encryption in response to Snowden's revelations. It was a project that was already well under way. Snowden's information did cause the project to be accelerated, though.

From what I saw, the main effect was that the tolerance for exceptions to the encryption requirement dropped basically to zero. In an enormous and complex infrastructure like Google's there are always dozens of corner cases where anything you'd like to do is really hard for one reason or another, and so big infrastructure changes tend to take years to fully deploy, to avoid requiring project teams to drop all their productive work in order to avoid breakage from the change. Snowden's data changed the encryption mandate from "You need to get this done as soon as you can" to "Encryption will be on 100% by date X, no exceptions. If you can't see how to make it work, come talk to us and we'll help." (X was single-digit weeks away).

I know one team who had to deploy a spit-and-baling-wire construction to enable their protocol to be encrypted, and then had to fight with serious performance degradation until they got a well-designed and tested replacement in place. They begged for permission to turn off encryption for a while so they could focus on building the solid replacement rather than spending their time fighting production fires caused by the interim solution... and they were denied. This was for an important production service related to financial systems, too, which gives you a good idea of how serious Google was about the encryption mandate.

Thank you, Edward Snowden!

(I want to be sure no one thinks that last line is sarcastic. It's not. At all. I think Edward Snowden is one of the great American heroes, and I think that history will eventually give him his considerable due. I don't know anyone on the team I mentioned who would disagree, either, even though it caused them some weeks of long hours and stress.)

Comment: Re:Lots of great features and no kdbus (Score 1) 116 116

I'm not sure what encryption is useful for. If my servers get hacked, they're able to read encrypted files.

You mention laptops and mobile devices, and claim that they get hacked way more often than they get lost/stolen. This is absolutely not true. Look at the many, many instances of laptops being lost or stolen with sensitive databases on them, and the ones that get reported publicly are just a tiny fraction.

It's also not necessarily the case with ext4 encryption that a box getting hacked reveals all of the data on it. Ext4 encryption allows each user account -- or even various subdirectory, IIRC -- to have its own keys. So a hacker can only get access to the directories whose keys have been loaded into memory. So the attacker has to own the box and then maintain ownership and connectivity until the data he's after has been unlocked.

You're also ignoring implementations which use hardware-based keys (HSM or similar) with other access controls on key usage, potentially even including rate limiting. So even if an attacker manages full privilege escalation and fully owns the box, he can't get access to anything encrypted unless he can satisfy the other access control requirements, and may also be rate-limited.

Malware on my Android device can read my encrypted files as soon as I get the phone properly booted.

Only if said malware can manage a privilege escalation attack. Granted that this issue is orthogonal to disk encryption, which is all about protecting against attackers with physical access to a powered down (or, to a lesser extent) locked device.

Klein bottle for rent -- inquire within.

Working...