Why not in addition to requiring a password... give the user a 255x255 grid (Total 65,000 boxes). Require the user to place 3 symbols on the grid, by clicking, not within the vicinity of any two symbols lining up horizontally, diagonally, or vertically, and not within a certain euclidian distance of any other symbol.

The symbol in a box can be placed in the center, left edge, right edge, bottom edge, top edge, upper-left corner, upper-right corner, lower-right corner, or lower-left corner.

In addition to the password, the placement of the symbols must be remembered (which box, and where in each box, each marker was placed).

The result is an extra ~19 bit field.

Then a heavy work-factor PBKDF2, BCrypt, or SCrypt hash of this 19-bit field could be appended to the password.

Thereby, creating a password augmentation that will be very difficult to brute force

You agree that Microsoft respects your privacy more than Google?

They both "respect" your privacy; your private information is very important to them, and they want to be sure they are the ones that get to monetize it first and foremost.

If they weren't careful in safeguarding your data sufficiently well against the prying eyes of others, they might be in danger of losing monetary value to competitors in the advertising biz.

How about this: Gold's innate value is about 3 to 5% more than Copper's innate value, but less than silver's innate value.

Their "financing" is 0% APR. A Galaxy S4 is $20/mo for 24 months and $149 down, the same $629 as pay-up-front.

Time value of money says there's no thing as a 0% APR. The vendor is making back the cost of that capital somehow, probably by including it up front, by increasing the initial loan amount, in the price of the phone, or in the price of the subscription.

I'd say that's very good for T-Mobile, except the predatory anti-consumer term that you immediately owe the remaining balance if you stop the service. That should hint at you that some part of the subscription fee is actually being used quietly to fund the cost of capital, including the risk component.

It does seem in poor taste that the original author choose to vent over a personal experience with some contact at Voltage in an Ask slashdot article, having perhaps done inadequate research, and/or asked inadequate questions to learn sufficiently about the solution before presenting to stakeholders.

I don't understand that... taking a trial of an enterprise software product, or at least reading all the technical manuals, should be key, before presenting it to stakeholders within one's own organization, as the solution, just as much as getting the pricing.

Well the government runs law enforcement, public education

The first two are done by state governments, not the feds. Maybe all the tax money should go to the states?

welfare, and infrastructure maintenance

Of which they do an absolutely horrible job. You're correct in that you can't personally afford it -- but for what the population is paying in taxes, we should get a hell of a lot more than what we're getting. Frankly, I think things would be better if they privatized it, and decided, whoever has the lowest bid gets to do it, as long as they meet certain standards -- through competition, taxpayers could get a more efficient deal.

Most code we write is concurrent by default since we do a lot of web applications.

I can see why some people might say that web applications are concurrent, but usually they are not. The ability to open up two copies of notepad.exe does not make notepad a concurrent program, and the same goes for web applications.

This is just the fact that concurrent independent instances can occur, as a result of an operating system with concurrent code. Normally the instances of a web application will be independent, and non-concurrent. If the instances of the web app are not independent, and they rely on common resources -- usually, the instances will have to lock resources, in order to remove that concurrency from the execution, resulting in a non-concurrent execution.

A web server can service 10 simultaneous requests; that's not necessarily concurrent, the simultaneous requests may be managed in one series of execution using a polling loop.

Often for performance purposes, once a connection is ready, it may be handed off to a child process, that performs sequential (non-concurrent) processing of the request.

In effect... the developers of web servers, and web applications, are very good at taking advantage of parallelism at the presentation layer, with limited as much as possible, or no concurrency

I totally agree this is the ideal situation. The problem is, many e-mail clients don't provide easy-to-use encryption; they require a lot of work from the end user, they don't make it simple enough -- and they don't implement both S/MIME and GPG / OpenPGP, so there are two conflicting standards.

S/MIME has a higher barrier to entry, due to the need for the end user to purchase, or otherwise obtain a personal X509 certificate; typically requiring a formal certificate enrollment process, then the certificate is only good for a limited amount of time, and the user has to repeat this inconvenience every 1 to 3 years.

Some e-mail clients such as Outlook and iPhones have supported S/MIME. In MS exchange, previously, Outlook Web Access in Exchange supported some "S/MIME browser plugin" that could be used to decrypt mail, however, support for that capability from OWA has been discontinued and removed as of Exchange 2013.

GPG/PGP again have the problem of lacking or no native support on common e-mail clients.

These usability challenges make a gateway, with possible use of TLS encryption between client and mail gateway, a more realistic idea, in most cases.

One issue with encrypted messages however, is that unless your mail filters have the private keys they cannot look inside the encrypted mail for spam or malware...

Don't read encrypted mail that is also not signed. If the signer is not in your contact list, then reject the message. To be clear, this should be done in software, that automatically executes this based on IT defined policies.

In practice, spammers and automatic malware rarely if ever encrypt the message. One of the main reasons would be users would have no idea to decrypt, also, it takes computational work to encrypt a message; which would add up very quickly if sending a lot of messages.

That's also a way of deterring spammers -- only implement message decryption techniques that required significant computational work to encrypt the message; in fact require a proof of work in every email, equivalent to approximately 2 to 3 minutes worth of an average workstation's compute time, before a decrypted message will be displayed.

For the sender it would be a minor annoyance.... for spammers, it could be crippling.

seem like a gimmick. taking steps like ensuring your MTA always delivers using a TLS connection is probably the most interoperable decision

This is a good first step, but protects the transport not the message.

If you want the message to be secure, the end should encrypt the message, then transmit it over a MTA that leverages TLS to further protect the transportation of the encrypted message payload, hop-by-hop, until the encrypted message is downloaded to the authorized reader's computer, AND then, the software on the authorized reader's computer decrypts and displays the message using a secure viewer (without writing any part of the file to disk), after the authorized user inserts their hardware security module (HSM / Smartcard), and types their secret passphrase.

Unfortunately, the solution of "let joe do it" opens you up not only to joe, but also to anyone who snoops the unencrypted transmission between Gladys and joe.

You can still use crypto to secure the transmission from Gladys to Joe; as long as you trust Joe, use a TLS encrypted session from Gladys to Joe. E.g. SMTP over TLS to the gateway, with Gladys' username, and password + OTP token generated key to authenticate Gladys to Joe.

Concurrent code isn't new. If this guy doesn't understand it then his problem isn't that he has neglected to stay current, but that he was never very skilled to begin with.

Maybe it's just that writing concurrent code is hard, annoying, prone to buggy results, and should be avoided, except in special circumstances where there is a great advantage.

I think the carriers should be required to eliminate termination fees, and structure the payment situation differently

Instead of being allowed to have a 2 year contract, you pay for: (1) Financing charges on your phone. You have an option of either paying up front for the phone, fair market value. Or financing the phone; instead of a "$200 termination fee"; you have a principal balance on your loan for the phone.

Instead of having a subsidy hidden within the monthly fee, you have: (1) a monthly subscription fee, and (2) a monthly installment on the financing for your smart phone.

Then if you leave providers, you don't pay a $200 termination fee. You have the option to continue to make the repayment on your financing, and you have a right to unlock your phone and take it to the competitor, instead of having to get a new smartphone, and a new financing agreement.

Furthermore, once the financing is paid off, your monthly price decreases, since the providers are required to keep the subscription fee separate in that case;

That differs from the current situation, where you continue to pay the same high price, whether the carrier is currently financing your smart phone, or you chose to purchase it outright, or got a cheaper phone subsidized, or a more expensive one....

Ok, but i'm supposed to be persuaded by a hash which supposedly existed -- which was removed, that could supposedly only be generated by a Microsoft employee, contracter, partner, or other entity with some level of read access to the Windows source code materials?

And could only be verified by another person with similar acces.... and, they would be unlikely to pull the document to verify, as downloading the revision, could implicate them as an accomplice, when Microsoft's IT security will review the audit logs on all their servers laptops and workstations, to figure out who exactly downloaded, read, or accessed the document(s) the hash was taken against, and when.

So for all I (or any member of the community) knows, the hash was incorect or bogus, only because we don't actually have the means to verify, or a known verified Microsoft person standing up to corroborate the anonymous poster's status.

If I was his manager and knew who it was, I would fire him immediately. Otherwise I would be risking him "venting" again in the future and embarrassing me even further. He is probably in violation of his employment agreements

How do we know he/she isn't an Apple developer, slapping on the name Microsoft to hide his/her identity?