Then check the voltages/resistances between D+ and D- of an Apple "dumb charger" for compliance to that specification.
Or take my word for it: It will fail. Floating one pin at 2.0 volts and one at 2.8 with resistive voltage dividers is NOT compliant with that specification.
If I post something to Facebook, I have explicitly shared it in a point-to-multipoint fashion. I have an expectation that it might get disseminated in some fashion, thus I control what gets published there. (Even for stuff that I post with some level of privacy restrictions - it's stuff that is less "private" than some other methods of communication.) - e.g. Facebook's privacy track record is shit, so I don't really trust them except for shit that just doesn't really matter.
However, the NSA has been going after methods of communication where people have a higher level of privacy. Google has a VERY good track record of protecting its customer's privacy, therefore I trust Google to transfer my emails and IMs to whomever I'm having a conversation with (usually a point-to-point one) without giving out the content of those transfers.
Similarly, I assume AT&T isn't mass-monitoring the content of my phone calls (technically infeasible). After the Carrier IQ fiasco, I don't trust them with easier to collect stuff though (text messages, when calls were placed to whom...) When I find out someone with the technical infrastructure to mass monitor call content is overstepping their bounds and likely assisting AT&T with such things - THAT pisses me off.
TL;DR - People don't actually trust Facebook and control what goes there. People are pissed that the NSA has been fucking around with communications methods we traditionally trust.
" The AOSP patch addresses the part of Jellybean that verifies the cryptographic signature of sideloaded apps. That has to be updated on the device end--it's the "Verify Apps" option in the security menu."
Nope. Those are two separate things. The "Verify Apps" operation applies some or all of the same Play Store checks to sideloaded apps, and I believe is only available with gapps installed (I'll poke at that this weekend.)
The signature verification is part of the core Android system (even without gapps) and has been since long before that "Verify Apps" feature existed.
If the signature verification vulnerability is patched on a given device, the "verify apps" and Play Store scanning becomes unnecessary (but still a good idea for defense in depth)
If the signature verification vulnerability is not patched on a given device, the "Verify Apps" function should still act as a line of protection for sideloads.
Was this a Dreamliner that had fixes for the previous problems applied burning, or was this a case of an airline cheaping out and not installing a strongly recommended/required fix?
That was the word Bluebox used to describe it... Honestly, their original press release blew this way out of proportion.
Most Android devices now have support for scanning of sideloaded APKs for Malware now (it's a Google Play service), and I'm assuming that while a week or two ago that detector wasn't configured to detect this exploit, it almost surely does by now.
Same in the US. Honestly, for cable/DSL, we don't have per-gigabyte charges (Well, comcrap tried a 250GB cap at one point, dunno if that's still there...)
However, our upstream bandwidth is so pathetically low that uploading 100GB would take about 55 hours. (assuming 500 kilobit upload, which is sadly near the upper end of the spectrum once you put DSL into the picture...)
While we can write that amount to a hard drive in minutes.
Also note that I believe Google is now scanning for APKs that have duplicate file entries - so this should (or will soon) get blocked right in the Play Store even with a trusted account, and also will likely get caught by Google's sideload malware scanning capabilities.
In short, this "master key" is of no impact to any user that applies the most basic levels of common sense (don't sideload shit from sources you don't trust.)
Yeah... Altera is the first company that Intel has sold excess manufacturing capacity to in years (if ever?), and in that case, Altera's primary products are in a market that does not compete with Intel's at all, and if anything, complements Intel's products in some cases.
Intel selling manufacturing for a competing CPU design is highly unlikely.
It appears that Intel primarily scales their fabs to meet only their own demand - there is only extra if one of their product lines experiences significantly less demand than expected. You can sell available spare capacity to a low-volume customer like Altera - but Apple? Highly unlikely even if they weren't being asked to produce a competing product.
Unfortunately, as I understand it, a copyright holder has to actually go forward with a suit.
The Busybox guys are quite willing to do this, but as I understand it, most of the kernel guys don't bother. For most companies, just the bad PR alone is enough to ensure compliance (unless the company is Chinese - Oppo is one of the only Chinese manufacturers to bother with GPL compliance, the rest just don't give a shit), but Samsung seems to think they can override that with their marketing budget. Nearly all GPL enforcement suits are over Busybox, not the kernel.
Yeah. Unfortunately, the issues he presents here DO make it more difficult to prove that someone is providing a binary that could NOT have possibly originated from the provided source code.
As an example, the kernel source initially released for the Samsung GT-N8013 (USA Wifi Note 10.1) was not what was used to build the binaries in question.
The "difficult to prove but obvious" - Any kernel built from the provided source had a massively broken wifi driver that would completely stop functioning, usually within 5-10 minutes, requiring the module to be removed and reinserted. Pulling the wifi module source from a different Samsung tarball (such as a GT-I9300 release) would result in a working driver. But how do you prove the source provided is correct? In the case of the N8013, we were lucky - Samsung changed a bunch of debug printk()s slightly in their released binary. Small stuff, not functionally relevant, such as typo fixes and capitalization differences in their touchscreen driver's debug printk()s - but at least provable to be different.
So we could prove that the kernels didn't match, but couldn't necessarily prove that the biggest functional problem was due to a source difference.
We asked Samsung to provide source that corresponded to the UEALGB build for that device, and their response was, "That build is a leak and hence we are not obligated to provide source for it." Effectively admitting that the provided source was not meeting the requirements imposed by the GPL for that build, and then claiming that the software build preinstalled on every device sold in the USA for the first 1-2 months after launch was a "leak" and thus they didn't have to provide source for it.
Needless to say, between that and other situations, that was my last Samsung device.
Wrong. Nearly all tube-style fluorescents refresh at 60 (or 120 - one per half cycle) Hz.
High frequency electronic ballasts are RARE for tube-style fluorescents. CFLs are a different story - nearly all of these have high frequency electronic ballasts these days - but the "tube" style fixtures found in offices rarely have high frequency ballasts and use passive reactive ballasts instead.
LED PWM frequencies are FAR higher than the old CRT refresh rates.
Also, while the OP talks about phosphor persistence, remember, the duty cycle of CRTs was VERY short. A pixel would only be "energized" for a tiny fraction of each display cycle. Even with phosphor persistence, I would not be surprised if even at very low brightness levels, PWMed LED backlights are still at a higher duty cycle than CRTs.
I have a friend who is extremely photosensitive - the flicker of fluorescent lights without high frequency ballasts make him begin feeling sick almost immediately, and before he was on seizure medications, would cause seizures. To use a PC monitor, he had to always have ultra-high-refresh rate CRTs - until LCDs became common. He has NEVER had ANY issues with any LCD monitor, regardless of whether the backlight was LED or CCFL. They have been a godsend for him.
Sony does indeed not have a good track record... However, they do have a consistent track record of poor financial performance that correlates with their anti-consumer policies.
Sony has been under new management for a year or two, and it seems like Kaz actually has a clue, understanding basic concepts like "treating your customers like shit is bad for business".
Look, for example, at Sony Mobile, which started out as a joint venture between Sony and Ericsson. For a long time, it was thought that Sony Mobile's dedication to open source and developer-friendliness was an anomaly that would go away when Sony bought out Ericsson's share - but just the opposite has happened. The opensource guys at Sony Mobile are being given even MORE freedom as time goes by, Sony is becoming MORE developer-friendly - and there's now evidence that this attitude is starting to migrate to other business units.
Thorium has some pretty nasty proliferation risks.
However uranium/plutonium-based fuel cycles involving fast reactors and advanced reprocessing (such as the IFR) are far less of a proliferation risk and would be able to generate, if I recall correctly, 100% of this country's electricity for 50-100 years using only our current waste reserves from older reactors. In addition, the end "waste" product of an IFR fuel cycle decays to lower radiation levels than the initial unenriched uranium after approx. 200 years (200 years of safe storage is much easier than 10,000+)
I don't think so. Note the cost estimates for a program of supposedly massive scale: $20M/year.
That one number completely destroys the credibility of the slides. Even if you multiplied that number by 10 it would probably still be a bit on the low side.
You obviously don't have a fucking clue about how classified data is protected, since none of those attacks are valid unless someone royally screws up. (And such screwups have harsh penalties for someone's career.) Again leading to "compromise someone with access to such information" as the primary attack method.
The question is - was the information really that sensitive, or was it the stuff not sensitive enough to be considered classified?
To get anything more sensitive than FOUO, these "hackers" would have had to physically infiltrate a facility, break NSA Type 1 crypto protocols (in which case the DoD would be shitting their pants), or compromise someone with access to such information.
Yeah. Mumble, TeamSpeak, Ventrilo - none are a good replacement for just shouting out loud.
Some of the most fun I've ever had gaming was a DAoC LAN party many years ago - I drove down to visit one of my guildies, and his GF (now wife), some friends, and their GFs (also guildies) were all there. We broke out the beer and the switches and went RvRing the whole weekend. "HIBS INC NW!" sounds so different when shouted in a friends' apartment.:)
There are currently almost NO tablets with Qualcomm processors.
I think one Lenovo unit has some sort of Qcom in it. Sony's Tablet Z has an APQ8064, but it hasn't hit the market outside of Japan yet. I can't think of any other examples really - but Qualcomm DOMINATES in phones right now.
The tablet situation might change at I/O - lots of rumors that the Nexus 7's replacement will be Qualcomm-based.
NVidia and TI have, so far, been dominating the Android tablet market. iPads have been Samsung-manufactured Apple-designed so far.
The GPU isn't the problem. It's the fact that Allwinner still hasn't created an Android OMX stack for their hwaccel video codecs.
People don't understand that the ARM SoC world is different than the desktop world - in the desktop world, EVERYTHING graphics-related is on the GPU, and it's all blobbed up.
In the ARM SoC world, the graphics subsystem is split up significantly, with a lot of mix-and-match opportunities.
For example, Mali 400MP GPUs are found in a wide variety of SoCs - Samsung Exynos4, Allwinner, Amlogic chips, Rockchip RK3066, some MediaTek chips, and I think a few others. People say, "when will there be hwaccel on Mali" - the answer is NEVER. This is because hwaccel video decoding is done by separate components in the SoC. In the case of Samsung Exynos, it's Samsung's MFC. In the case of Qualcomm, it's "vidc". In the case of Allwinner, it's CedarX. Amlogic's is just "amplayer" or something like that. FYI, at least the kernel interfaces (albeit not the firmware) for MFC and vidc are open-source, as are OMX stacks for both of those implementations.
You can also see other interesting pairings too - for example, Samsung's MFC engine is very similar between Exynos3 and Exynos4, despite Exynos3 having a PowerVR GPU, and Exynos4 having Mali 400MP.
Samsung's MFC has "good enough" OMX support to do XBMC on Exynos3, 4, and 5. Allwinner simply has NO OMX decoding solution for Android using CedarX, only their special proprietary player. Same for Amlogic's amplayer - the only reason XBMC works with Amlogic chips is because XBMC had "special" nonstandard playback support added.
There are limitations to the pump: 1) If the pump has any sort of problems, you need to start taking fast-acting injections once every hour or two, since you no longer have a nice Lantus baseline. You can get into a VERY bad state in a matter of hours from various people I've talked to. 2) Pumps simply can't handle certain environments. Part of my job includes running EMI tests in an aircraft hangar on occasion - I'd have to remove my pump and go to hourly injections for the duration of such tests.
Slashdot Mirror
"The Apple charger has a standard USB power port."
Wrong.
http://www.usb.org/developers/devclass_docs
Read the v1.2 specification.
Then check the voltages/resistances between D+ and D- of an Apple "dumb charger" for compliance to that specification.
Or take my word for it: It will fail. Floating one pin at 2.0 volts and one at 2.8 with resistive voltage dividers is NOT compliant with that specification.
There's also a difference in the data collected:
If I post something to Facebook, I have explicitly shared it in a point-to-multipoint fashion. I have an expectation that it might get disseminated in some fashion, thus I control what gets published there. (Even for stuff that I post with some level of privacy restrictions - it's stuff that is less "private" than some other methods of communication.) - e.g. Facebook's privacy track record is shit, so I don't really trust them except for shit that just doesn't really matter.
However, the NSA has been going after methods of communication where people have a higher level of privacy. Google has a VERY good track record of protecting its customer's privacy, therefore I trust Google to transfer my emails and IMs to whomever I'm having a conversation with (usually a point-to-point one) without giving out the content of those transfers.
Similarly, I assume AT&T isn't mass-monitoring the content of my phone calls (technically infeasible). After the Carrier IQ fiasco, I don't trust them with easier to collect stuff though (text messages, when calls were placed to whom...) When I find out someone with the technical infrastructure to mass monitor call content is overstepping their bounds and likely assisting AT&T with such things - THAT pisses me off.
TL;DR - People don't actually trust Facebook and control what goes there. People are pissed that the NSA has been fucking around with communications methods we traditionally trust.
" The AOSP patch addresses the part of Jellybean that verifies the cryptographic signature of sideloaded apps. That has to be updated on the device end--it's the "Verify Apps" option in the security menu."
Nope. Those are two separate things. The "Verify Apps" operation applies some or all of the same Play Store checks to sideloaded apps, and I believe is only available with gapps installed (I'll poke at that this weekend.)
The signature verification is part of the core Android system (even without gapps) and has been since long before that "Verify Apps" feature existed.
If the signature verification vulnerability is patched on a given device, the "verify apps" and Play Store scanning becomes unnecessary (but still a good idea for defense in depth)
If the signature verification vulnerability is not patched on a given device, the "Verify Apps" function should still act as a line of protection for sideloads.
That's a good question.
Was this a Dreamliner that had fixes for the previous problems applied burning, or was this a case of an airline cheaping out and not installing a strongly recommended/required fix?
That was the word Bluebox used to describe it... Honestly, their original press release blew this way out of proportion.
Most Android devices now have support for scanning of sideloaded APKs for Malware now (it's a Google Play service), and I'm assuming that while a week or two ago that detector wasn't configured to detect this exploit, it almost surely does by now.
Same in the US. Honestly, for cable/DSL, we don't have per-gigabyte charges (Well, comcrap tried a 250GB cap at one point, dunno if that's still there...)
However, our upstream bandwidth is so pathetically low that uploading 100GB would take about 55 hours. (assuming 500 kilobit upload, which is sadly near the upper end of the spectrum once you put DSL into the picture...)
While we can write that amount to a hard drive in minutes.
I think the thing is there are ALREADY various penalties for being a smoker... The new Obamacare rules conflict with those penalties.
That said, I don't see what the big deal is here... If anyone should be discouraged from being a smoker by a penalty, it is someone who is young.
Also note that I believe Google is now scanning for APKs that have duplicate file entries - so this should (or will soon) get blocked right in the Play Store even with a trusted account, and also will likely get caught by Google's sideload malware scanning capabilities.
In short, this "master key" is of no impact to any user that applies the most basic levels of common sense (don't sideload shit from sources you don't trust.)
Yeah... Altera is the first company that Intel has sold excess manufacturing capacity to in years (if ever?), and in that case, Altera's primary products are in a market that does not compete with Intel's at all, and if anything, complements Intel's products in some cases.
Intel selling manufacturing for a competing CPU design is highly unlikely.
It appears that Intel primarily scales their fabs to meet only their own demand - there is only extra if one of their product lines experiences significantly less demand than expected. You can sell available spare capacity to a low-volume customer like Altera - but Apple? Highly unlikely even if they weren't being asked to produce a competing product.
Unfortunately, as I understand it, a copyright holder has to actually go forward with a suit.
The Busybox guys are quite willing to do this, but as I understand it, most of the kernel guys don't bother. For most companies, just the bad PR alone is enough to ensure compliance (unless the company is Chinese - Oppo is one of the only Chinese manufacturers to bother with GPL compliance, the rest just don't give a shit), but Samsung seems to think they can override that with their marketing budget. Nearly all GPL enforcement suits are over Busybox, not the kernel.
Yeah. Unfortunately, the issues he presents here DO make it more difficult to prove that someone is providing a binary that could NOT have possibly originated from the provided source code.
As an example, the kernel source initially released for the Samsung GT-N8013 (USA Wifi Note 10.1) was not what was used to build the binaries in question.
The "difficult to prove but obvious" - Any kernel built from the provided source had a massively broken wifi driver that would completely stop functioning, usually within 5-10 minutes, requiring the module to be removed and reinserted. Pulling the wifi module source from a different Samsung tarball (such as a GT-I9300 release) would result in a working driver. But how do you prove the source provided is correct?
In the case of the N8013, we were lucky - Samsung changed a bunch of debug printk()s slightly in their released binary. Small stuff, not functionally relevant, such as typo fixes and capitalization differences in their touchscreen driver's debug printk()s - but at least provable to be different.
So we could prove that the kernels didn't match, but couldn't necessarily prove that the biggest functional problem was due to a source difference.
We asked Samsung to provide source that corresponded to the UEALGB build for that device, and their response was, "That build is a leak and hence we are not obligated to provide source for it." Effectively admitting that the provided source was not meeting the requirements imposed by the GPL for that build, and then claiming that the software build preinstalled on every device sold in the USA for the first 1-2 months after launch was a "leak" and thus they didn't have to provide source for it.
Needless to say, between that and other situations, that was my last Samsung device.
Wrong. Nearly all tube-style fluorescents refresh at 60 (or 120 - one per half cycle) Hz.
High frequency electronic ballasts are RARE for tube-style fluorescents. CFLs are a different story - nearly all of these have high frequency electronic ballasts these days - but the "tube" style fixtures found in offices rarely have high frequency ballasts and use passive reactive ballasts instead.
I'm positive it's placebo here.
LED PWM frequencies are FAR higher than the old CRT refresh rates.
Also, while the OP talks about phosphor persistence, remember, the duty cycle of CRTs was VERY short. A pixel would only be "energized" for a tiny fraction of each display cycle. Even with phosphor persistence, I would not be surprised if even at very low brightness levels, PWMed LED backlights are still at a higher duty cycle than CRTs.
I have a friend who is extremely photosensitive - the flicker of fluorescent lights without high frequency ballasts make him begin feeling sick almost immediately, and before he was on seizure medications, would cause seizures. To use a PC monitor, he had to always have ultra-high-refresh rate CRTs - until LCDs became common. He has NEVER had ANY issues with any LCD monitor, regardless of whether the backlight was LED or CCFL. They have been a godsend for him.
Sony does indeed not have a good track record... However, they do have a consistent track record of poor financial performance that correlates with their anti-consumer policies.
Sony has been under new management for a year or two, and it seems like Kaz actually has a clue, understanding basic concepts like "treating your customers like shit is bad for business".
Look, for example, at Sony Mobile, which started out as a joint venture between Sony and Ericsson. For a long time, it was thought that Sony Mobile's dedication to open source and developer-friendliness was an anomaly that would go away when Sony bought out Ericsson's share - but just the opposite has happened. The opensource guys at Sony Mobile are being given even MORE freedom as time goes by, Sony is becoming MORE developer-friendly - and there's now evidence that this attitude is starting to migrate to other business units.
Thorium has some pretty nasty proliferation risks.
However uranium/plutonium-based fuel cycles involving fast reactors and advanced reprocessing (such as the IFR) are far less of a proliferation risk and would be able to generate, if I recall correctly, 100% of this country's electricity for 50-100 years using only our current waste reserves from older reactors. In addition, the end "waste" product of an IFR fuel cycle decays to lower radiation levels than the initial unenriched uranium after approx. 200 years (200 years of safe storage is much easier than 10,000+)
"Second, the Powerpoint is legitimate"
I don't think so. Note the cost estimates for a program of supposedly massive scale: $20M/year.
That one number completely destroys the credibility of the slides. Even if you multiplied that number by 10 it would probably still be a bit on the low side.
You obviously don't have a fucking clue about how classified data is protected, since none of those attacks are valid unless someone royally screws up. (And such screwups have harsh penalties for someone's career.) Again leading to "compromise someone with access to such information" as the primary attack method.
So - have a lesson on forkbombs prepared for when that happens.
Um, who ever said they were? They most definitely are not.
The question is - was the information really that sensitive, or was it the stuff not sensitive enough to be considered classified?
To get anything more sensitive than FOUO, these "hackers" would have had to physically infiltrate a facility, break NSA Type 1 crypto protocols (in which case the DoD would be shitting their pants), or compromise someone with access to such information.
Yeah. Mumble, TeamSpeak, Ventrilo - none are a good replacement for just shouting out loud.
Some of the most fun I've ever had gaming was a DAoC LAN party many years ago - I drove down to visit one of my guildies, and his GF (now wife), some friends, and their GFs (also guildies) were all there. We broke out the beer and the switches and went RvRing the whole weekend. "HIBS INC NW!" sounds so different when shouted in a friends' apartment. :)
There are currently almost NO tablets with Qualcomm processors.
I think one Lenovo unit has some sort of Qcom in it. Sony's Tablet Z has an APQ8064, but it hasn't hit the market outside of Japan yet. I can't think of any other examples really - but Qualcomm DOMINATES in phones right now.
The tablet situation might change at I/O - lots of rumors that the Nexus 7's replacement will be Qualcomm-based.
NVidia and TI have, so far, been dominating the Android tablet market. iPads have been Samsung-manufactured Apple-designed so far.
The GPU isn't the problem. It's the fact that Allwinner still hasn't created an Android OMX stack for their hwaccel video codecs.
People don't understand that the ARM SoC world is different than the desktop world - in the desktop world, EVERYTHING graphics-related is on the GPU, and it's all blobbed up.
In the ARM SoC world, the graphics subsystem is split up significantly, with a lot of mix-and-match opportunities.
For example, Mali 400MP GPUs are found in a wide variety of SoCs - Samsung Exynos4, Allwinner, Amlogic chips, Rockchip RK3066, some MediaTek chips, and I think a few others. People say, "when will there be hwaccel on Mali" - the answer is NEVER. This is because hwaccel video decoding is done by separate components in the SoC. In the case of Samsung Exynos, it's Samsung's MFC. In the case of Qualcomm, it's "vidc". In the case of Allwinner, it's CedarX. Amlogic's is just "amplayer" or something like that. FYI, at least the kernel interfaces (albeit not the firmware) for MFC and vidc are open-source, as are OMX stacks for both of those implementations.
You can also see other interesting pairings too - for example, Samsung's MFC engine is very similar between Exynos3 and Exynos4, despite Exynos3 having a PowerVR GPU, and Exynos4 having Mali 400MP.
Samsung's MFC has "good enough" OMX support to do XBMC on Exynos3, 4, and 5.
Allwinner simply has NO OMX decoding solution for Android using CedarX, only their special proprietary player.
Same for Amlogic's amplayer - the only reason XBMC works with Amlogic chips is because XBMC had "special" nonstandard playback support added.
The end result is a lot of people.
There are limitations to the pump:
1) If the pump has any sort of problems, you need to start taking fast-acting injections once every hour or two, since you no longer have a nice Lantus baseline. You can get into a VERY bad state in a matter of hours from various people I've talked to.
2) Pumps simply can't handle certain environments. Part of my job includes running EMI tests in an aircraft hangar on occasion - I'd have to remove my pump and go to hourly injections for the duration of such tests.
Last time I tried editing OSM it was a total and complete nightmare. That was a few years ago.
The new editor is a MASSIVE leap forward compared to whatever the hell I used before.