If Google fixes it in AOSP then you can at least grab a fixed version with Cyanogenmod or other custom builds. At least for tech folks the main thing holding them back from moving up may be device drivers for the newer kernel.

It's not in the current builds yet.

Have you tried delivering the same level of automation to your Mac users that most corporate Windows users get?

Honestly, no, because it's ~2% of our user base so you would never get an ROI on the tools or the time to learn them. Now for an F-25 2% of the userbase might be enough justify a team to purchase and learn Mac specific tools, but for those of us in the SME space there's no way it works out. Now, the MDM angle is interesting, I'll have to look into what support Maas360 offers for Mac, but it doesn't change things like no GPO equivalent to manage settings and the fact that Apple does things like ban older versions of JRE from running (we have a handful of systems that require ridiculously old version of the JRE, under Windows I can just whitelist them for those sites)

Huh? I bought my Galaxy S5 Developer Edition directly from Samsung and use it on Verizon with no issues, we also buy iphones from Apple and use them on Verizon without any problems. The main issue with Verizon is that you need a phone that supports their bands, which until recently was only available through them as they tended to be one offs, now Qualcomm is including almost all bands in universal chips and the 2g/3g chips tend to have support for both GSM and CDMA. Now I will grant you, before LTE brought SIM cards to Verizons provisioning process the only way to effectively get a phone activated was to buy it through them so the IMEI was in their supported database, but these days it's rather easy.

The only job I've ever been drug tested for was one requiring clearance.

The other thing is that they are also freeing up a tremendous amount of tax dollars from the general fund by not arresting, trying, and housing non-violent drug offenders. My guess would be those savings absolutely dwarf the tax revenue. Also there's a societal benefit, fewer people labelled as criminals means more people able to access gainful employment outside menial entry level jobs which should lead to a higher GDP.

Uh, Windows 10 uses the same driver model as Vista, 7, 8, and 8.1. It even comes in a 32bit version (8.1 was supposed to be the last 32bit Windows, but MS must really want Enterprises with broken legacy crap to move up) so as long as your printer has a Vista+ driver you should be fine.

Actually, it's going to be a bit cooler than that, if you have a touch device then metro apps will by default work like they do in 8, if not they'll be windowed, and if you have a convertible like the Surface Pro line then it will change behavior depending on the current configuration (again, by default, MS has heard the masses and will allow you to tweak the behavior).

Windows 10 is where the enterprise is going. I literally just got out of a meeting where we were discussing our goals for the year and Office 2013 and probably Windows 10 (depending on launch date and apparent buginess) are on the list. As far as your MBP, that's fine for you if you work in IT, but if you think most businesses are going to give every worker drone an expensive Mac with about 5-10x the support cost (as in I have numbers that show our Mac users cost that much more depending on their level of competence/IT independance) you're delusional.

Most apps use MMS which does include the equivalent of To: headers so all the parties can see who's in the conversation and you can do a reply all.

DMCA is evil, all of it.

Not at all, the compulsory licensing parts of it are why many services are available in the US and not in other countries and the safeharbor provisions are probably the only reason we still have search engines.

Uh, no from the paper they are hijacking an existing challenge/response session with a valid signed SAML assertion but exploiting a weakness where the code that validates the assertion and the code that reads the claim token are not necessarily checking the same part of the response and so they can insert a bogus claim ticket with a valid assertion. This would require intercepting the assertion response and modifying it, and since the whole conversation is within a TLS session it requires some kind of MitM attack.

But thinking on it further, you could use it as a privilege escalation attack, use a compromised user account to receive a valid assertion but modify your response to include the bogus claim ticket to login as a more privileged account, that's a lot more concerning as it's a lot easier to compromise a single account then pull off a MitM attack.

That's cool, and I appreciate the security researchers and their work to strengthen both protocols and implementations, but in the real world the entire conversation happens inside a TLS stream so it's not that easy, not only do you have to insert yourself into the communications path between the user and the resource, but you have to break TLS in realtime. It does increase the scope of attacks like BEAST/CRIME/POODLE a bit, but since that paper is almost 3 years old you would hope that at least the major providers have patched frameworks in place.

SAML has all authentication happen at the IDP (user organization side), not at the relying party/service provider so any login attempts are at your SAML endpoint. In theory you could even not allow passwords at the SAML point at all (if you have all your machines Kerberos joined you could use the Kerberos claim ticket to generate the SAML assertion and not have an alternate fallback authentication method, but for convenience and interoperability that isn't usually the case and there's generally a forms based login, in our case we have 3rd parties that use our cloud resources and have accounts in our authentication realm but not machines supplied by us so a forms bases login is a requirement). If an attacker wants to try to brute force one of your logins they have to do it at your SAML endpoint which you can and really should monitor tightly with all your normal tools, in fact since it's a single source of failure for security (the flipside of single signon) it should be better monitored than your average server.

Control is an illusion, if the folks at RSA can be spearfished and have their most valuable assets stolen basically anyone can. People are fallible and the bad guys only need one successful attack while the good guys need to defend perfectly. We run a relatively tight shop, no local admin, patches up to date, AV/Antispam on the email gateways, AV and Antimalware on the desktop, IDS/IPS in the firewall with additional IDS by spanning the vlans going to our firewall and the server vlan. What we've found is that we still end up with ~1% of our clients managing to get some kind of infection or infection attempt per month (the attempts are generally where an exploit of some kind succeeded but the payload was stopped by one of the defense layers from actually becoming persistent on the client).

As far as the point from the article, we're moving to have as many of our cloud apps as possible use our SAML repository for authentication so that we can treat it as much as possible like an extension of our general security stance with password attempt monitoring, rate throttling and attack blocking, user lockout, etc. It doesn't help if the service itself is breached, but it at least stops the more casual authorized user leaks that seem to be one of the more common failures identified.