"Cell phones will be automatically registered at cell towers as soon as they are switched on."... err, as they usually do? Since otherwise, how would the cell company know how to route a call for you?
Of course TFA is in Chinese, and I don't know what it really says, but yeah, the very design of the cell network allows for such tracking, and there's a lot of potential for abuse there, whichever government does it.
I guess this is in response to the Arab protests, if you as the authority can see where people are gathered/gathering, you know where to send the skull-crackers to.
Oh, and logging individuals would make it easier to see which people (phones) show up at these things regularly, for whatever reason, so we can crack their skulls too!
I wonder what sort of techniques can be used to fight this; multiple phones (useless since afaik you need an ID card to get a SIM card), leave your phone at home, go to "airplane mode" at a random time before the planned demo? Should the protesters buy walkie-talkies and tune to xy frequency? (The police would then just skull-crack anyone caught with a walkie-talkie).
There are still ways for critical people to remain safely anonymous under this circumstance. For example:
Leaders could receive donated phones from their supporters and remain anonymous.
A person could easily steal a phone from someone else and use it until it's deactivated, then steal another. If this person had a following, part of that group of followers could be tasked with maintaining a constant influx of stolen phones.
People could steal the phones of high-ranking officials or their families, or just random people, and bring them to protests to increase their own plausible deniability.
People could also steal or forge IDs when buying a phone, so that it's incorrectly registered.
That or China could legitimately be using this to monitor traffic density. I mean, traffic is a huge problem in several areas, and knowing the migration paths and times of citizens would be invaluable to devising an ideal solution.
A custom C library doesn't matter, if its 'native code' the C library is irrelevant as you're producing x86 machine code in the final NCI file.
To be safe, they essentially need to run it in a virtual machine without access outside the VM.
x86 code verifiers are about as useful as enabling heuristics detection in a virus scanners, the only thing they catch is something thats already more or less been seen in the exact same sort of form.
Maybe you should read up a bit on it before you make stupid comments. Their code verifier doesn't scan for known attacks (antivirus-style). Instead, Google has identified a subset of instructions which, when run in a specific sandboxed environment, eliminate the ability for the code to perform malicious activities. One pruning of the instruction set removes instructions that enable code to hide from the verifier (alignment requirements, removal of register jumps, etc.). The second constrains the instruction set, removing things like direct system calls, far jumps, etc.
The system also uses x86 segmentation capabilities to enforce a specific sandboxed execution environment. Doing this implicitly limits the scope of the code's branching and allows the verifier to make some critical assumptions that validate the assembly.
Rather than reproduce the paper, you should check out the link that I provided. Regardless, to say that the code verifier is not adequate is just foolish. The papers clearly explain, using logical proofs, how the various constraints enforced by the NaCl runtime, sandboxes, and code verifier are enforceable and provide reliable security. The "custom C library" is used in conjunction with the constraints to retain a general usefulness, facilitate inter-process communication (the primary mechanism of action), and work within NaCl constraints to perform higher-level operations like system calls.
I bought one. I'm not an Apple fanboy. This is, in fact, the second (alongside a third-generation iPod) Apple product that I've ever purchased. I've generally been rather anti-Apple, namely due to their shoddy Linux support (remembering early iPod days), their gross bloatware that is Windows iTunes (slash Safari, slash QuickTime, slash who the fuck knows), and my experiences working with Objective C and the Cocoa APIs professionally some early OSX builds.
That said, I went laptop shopping and, after soliciting several opinions, reading dozens of reviews, and looking at numerous potential models, I decided to go with the MBP. It was the only laptop (that I could find) that matched my criteria in terms of weight, battery life, touchpad functionality and size (was a huge selling point), keyboard layout, screen resolution, and power. I intend to use Boot Camp to dual-boot a Kubuntu distribution and will likely give both OSX and Kubuntu equal face-time. I also hope to contribute to various Linux drivers and software tweaks that target MBP hardware (camera, touchpad, etc.).
That said, let's talk Apple fanbois. I will use my experience with this device as almost my sole judge of my opinion of Apple software. How it boots, how it operates, and my experience with the UI will determine whether or not I become an Apple fanboy. I sincerely hope I do; from what I've seen, Apple is one of the few companies that is actually innovating in terms of user experience (I'll cite every music player, laptop, phone, and window manager that is playing catch-up; I understand things go deeper, Superkaramba, etc., but largely most modern composed UIs were first fully-realized by Apple). I really hope that Apple is as good as it seems on paper.
Now, granted, Apple has a negative reputation for several things. Overpriced hardware is one, for sure, but the one that really bothers me is their gatekeeper role in device software. I've always written this off because part of me definitely sympathizes with their perspective on users - that a device that "just works" is more valuable than an open platform. This definitely reflects what I've observed in the amateur computer user base, and is why I have an Android phone (and will never own an iPhone). If they had similar lockdowns of their notebooks, I'd feel similarly.
What Apple products need, I suspect, is a thriving open-source community, and looking at the thousands of Apple-targeting OSS projects out there, this seems to be the case. Just as with Windows, and MS-DOS before it, the open-source community needs to thrive in the face of adversity, provide compelling alternatives, and change both the foreground and background of the operating system - in other words, do what it does best.
And the point is that you have no say in the matter. You must "sit tight" and wait on Google to do something to save your valuable data. Yet, for some reason, you perceive a list of unanswered questions as a strength of the cloud, as if helplessly wondering what Google is going to do to save the data you've stored in its free service is an advantageous position to be in.
I do not perceive the strength of the cloud as a list of unanswered questions. I simply don't perceive a regular system error as an inherent cloud weakness. The unanswered questions, once answered, will determine whether or not this particular cloud is strong or weak. That a system has failed and that an error has occurred is not a statement on cloud-based services as a whole, but rather on Google as a cloud provider.
Anything you're comfortable handing to a local IT department could arguably have a cloud presence that is just as strong. The only difference is who's staffing the systems. Google's situation is very similar to the situation of any service provider, be it a cloud, an outsourced IT department, an in-house IT department, or yourself. If you don't believe that Google will sincerely do everything in their power to maintain their systems and recover from such failures, then so be it; don't use their services.
If you happen to be the type that simply considers anything they can't themselves fix to be inferior, then there's really no argument to be had. Have fun running everything.
Everybody knows that backups are good, cloud or no cloud. Everybody knows that things go wrong, cloud or no cloud.
The trouble is, that while you are correct, that the general populous makes the assumption that because you are in the cloud that there are no problems and that backups are required. I have had this argument myself before that the cloud is not perfect. And while you are at it throw in the additional fact that if the company hosting your cloud decides it is no longer profitable, then you better have a backup for that reason as well.
I agree, but the same population also makes the assumption that data is safe to begin with. This is the population that doesn't back up their local files, and likely can't properly recover them even if they did. This population likes to offload the problem of data or system failure to another technology - an external hard drive with backup software, an IT administrator, a cloud, etc.
To such a population, the possibility that the cloud might recover from failure is greater than the default solution (no backup); add the strength and competence of a company like Google into the mix and it'll likely surpass the other alternatives as well. I suspect the general population has a much better chance at overall data integrity and disaster recovery in a well-managed cloud than with any other solution.
For the rest of us, perhaps this is a timely reminder to backup our data and be less trusting of the cloud.
Okay, Slashdot, this is getting tiring. Every time a major cloud service fails, the inevitable "re-evaluate your trust in the cloud" mantra is mindlessly invoked. Everybody knows that backups are good, cloud or no cloud. Everybody knows that things go wrong, cloud or no cloud. So what's the real value-added to calling out cloud services every time something fails?
The interesting question is how the disaster is addressed. Will Google recover the data? Will it be quick? Seamless? If so, then the real lesson here isn't the weakness of the cloud, but rather its strength. Anything can go wrong with any system, but maybe Google's well-run cloud can handle the problem with minimal incidence.
So, Slashdot, rather than spouting off a thoughtless, ominous warning on every "something breaks in a cloud" story, how about you sit tight and see how this resolves?
I see this a lot in politics these days: educated, intelligent journalists lashing out and saying anyone who doesn't agree with their political opinions must not be a member of the human race. And here's one who thinks that it's OK to call for deaths just because she's frustrated.
There's a critical difference between a satirical call for death and an actual death threat. Death itself is a powerful subject, and it can be used quite aptly to evoke far more sentiment than straight murderous rampage. In this case, she wasn't stating her intent to kill Berlusconi, nor was she attempting to rally others to do the same. Rather, she was expressing her rage and frustration at him, which is well within (at least American) bounds of free speech.
This seizure wasn't made out of fear and concern for Berlusconi's wellbeing. This is textbook abuse of law for the purpose of silencing opposition.
America has the same thing, Sarah Palin's calls for violence incited her followers and real people died.
This is a really stupid example. Maybe read a little into things before echoing the political impulse. As outrageous and annoying as Palin is, there is no good reason to suspect she had anything to do with the shootings.
What is terrorism. It is through fear to change peoples behaviour or politics or whatever. If someone blows a bomb to kill plenty of people that is not terrorrism. If the another person blows a bomb to make people not buy windows, then that is terrorism.
If someone fears the tooth fairy and by showing pictures of the tooth fairy, that person can be averted from a certain tooth paste, then that is terrorism, no violence needed.
You seem to have a grossly-simplified take on the matter. While the definition of terrorism is (understandably) difficult to state, legally-accepted definitions range from straight-up "harming large amounts of people" to coercion. Your example suggests you see terrorism as identical to Coercion, which is one naive take on the matter. However, all of your examples fall under one legal definition of terrorism or another.
Here are a few definitions from the Wikipedia article:
"Terrorism sprouts from the existence of aggrieved groups. These aggrieved groups share two essential characteristics: they have specific political objectives, and they believe that violence is an inevitable means to achieve their political ends. The political dimension of terrorist violence is the key factor that distinguishes it from other crimes." - L. Ali Khan
"Terrorism is the deliberate, negligent, or reckless use of force against noncombatants, by state or nonstate actors for ideological ends and in the absence of a substantively just legal process." - David Rodin
"Terrorism is the deliberate use of violence aimed against civilians in order to achieve political ends" - Boaz Ganor
"An act is terrorist if and only if (1) it is committed by an individual or group of individuals privately, i.e. without the legitimate authority of a recognized state; (2) it is directed indiscriminately against non-combatants; (3) the goal of it is to achieve something politically relevant; (4) this goal is pursued by means of fear-provoking violence." - Daniel D. Novotny
So is Anonymous (or, rather, are those who have operated under that pseudonym) a terrorist organization? Core to all of these seem to be violent acts by non-state actors against noncombatants. It seems to me that Anonymous actors and targets match, so the real question is whether or not Anonymous' actions qualify as violent acts.
While some things (like hacking websites) seem more akin to vandalism, in that they are not intended to cause harm, others, like DDoS attacks, could very well be the Internet equivalent of a violent attack. However, putting a DDoS attack against Mastercard on the same level as a subway bombing so grossly trivializes the latter. I think, rather than attempt to pervert words by drawing Internet parallels, the Anonymous actors should be regarded as persons sympathetic to terrorist ideals, but not actually terrorists. Idealistic Internet Vandals seems more appropriate.
Significantly reduces Bing's legitimacy? Quite the contrary. It shows that their search bar is doing exactly what it is intended to do, track its users and see what content they find the most useful. If they enter a search term in any search engine, including Bing, it surely is getting tracked and then automatically updated in Bing's system. This shows that they have a great (and functioning) mechanism for tracking relevance among their users.
Quote the whole phrase. If Bing uses Google, it's less legitimate as an innovative search provider. Obviously, using (and improving upon) someone else's technology doesn't reduce the usefulness of your own technology. It just makes you a fork.
There are also many other types of situations where it a citation is not ethically required or even permitted.
Citation is not permitted in this case, because it would violate Google's trademark.
Saying "we use Google" doesn't violate Google's trademark at all. Saying "we are Google", on the other hand, does. Big difference.
It seems like this is publicly available information. Were there any stipulations, even if informal, on how that information could be used?
Nobody's saying this is illegal (... yet?). Rather, it significantly reduces Bing's legitimacy as an innovative search technology and as a competitor to Google. In literature, using someone else's work requires a citation. For all ethical purposes, Bing should be labelled "powered by Google".
It's nice, although not as quick as all that on my machine.
But what does this demonstrate? Anyone interested knows you can display arbitrary graphics using HTML5 canvas. Anyone with any sense knows you can calculate a view of a Julia set in Javascript. Add the two together, and it's inevitable that this demo would be possible.
Now, how about using Web sockets to set up some kind of P2P network whereby if someone else is viewing the same region as you are, your machines collaborate on the calculations...
That and the Mandelbrot / Julia sets are awesome to explore, and they can now be explored from your browser with no dependencies. Something doesn't have to demonstrate a new or innovative use of technology to be cool and worthwhile.
But this demo not only performs a significant number of floating-point calculations. It also utilizes several system cores, demonstrating (once again) the viability of an HTML5-equipped browser as an application platform.
chipsets are typically soldered onto motherboards, while CPUs are clipped into sockets.
in order to install a free-replacement CPU, you flip a clip and put in the new part. 5-10 minutes for an inexperienced tech (60 seconds for a l33t h4xx0r whose system is never truly buttoned-up), and one new part to check out.
in order to install a free-replacement chipset, you replace your motherboard. a couple of hours of unplugging, unscrewing, unpacking, re-screwing, chasing screws that fell off the desk, plugging back in, double-checking the plugging-in, going online to find a representative picture to be sure you put the memory in the optimal slots, and closing up the case. and then you have a hundred new parts to shake out.
Don't get me wrong, I don't think it's a lesser problem. I got the tone from the OP that he was confused how a CPU issue could cause such a specific and isolated problem with SATA, so I was pointing out how the problem wasn't with the Sandy Bridge CPU, but rather with the supporting chipset.
Obviously, silicon bugs happen, barely anything makes it out of the fab without an 'errata' list as long as your leg; but the "may gradually degrade over time" part kind of freaks me out.
If it were a "due to a design error, setting register xyz to 0xDEADBEEF causes Serious Badness, chipset drivers are being patched to Never Do That on rev.1 chipsets and future chipsets will be amended" that would be unfortunate; but so it goes. Fully deterministic errors, like the classic division bug, may be problematic; in some cases bad enough to qualify the product as just plain defective; but once known they can be mitigated by not stepping on them. Something that "sometimes" "gradually decreases" performance, on a bus with error correction, though, sounds a lot like a physical problem where some sort of silicon/electrical issue causes error rates to increase and thus retries/corrections to increase in frequency, and user-visible performance to go down. That makes me nervous. It sounds less like a deterministic error problem and more like a certain physical components are actually degrading much faster than expected problem...
Can anybody think of an explanation for how a hardware bug would cause behavior that gradually changes over time(in a manner that couldn't be dealt with with a driver update) that doesn't involve the alarming possibility of gradually increasing error rates and/or early death of onboard SATA ports?
Well, the flaw is with the Sandy Bridge chipset that accompanies the CPU, so it's not with the CPU itself. The http://en.wikipedia.org/wiki/Sandy_Bridge#Architecture includes, among other things, the IO and memory controller hub components, which control (between them) DMA and the actual SATA controller hardware and some of the relevant busses. I assume the problem is somewhere in there, and is hardware-related (i.e., not firmware-upgradeable).
A separate Jepsen press release suggested some of the blame for the privacy offenses laid with Google's victims, who were advised to 'turn off your wireless network when you know you won't use it' to thwart those who 'may be watching your Internet activity without your knowledge.
So from the actual link:
The consortium recommends:
Use anti-virus and anti-spyware and a firewall.
Turn off identifier broadcasting.
Change the identifier on your router from the default.
Change your router’s pre-set password for administration.
Turn off your wireless network when you know you won’t use it.
Don’t assume that public “hot spots” are secure.
Be careful about the information you access or send from a public wireless network.
Are you fucking kidding me? After all of this, the court case, the hearing, a formal consortium omits the single most important and critical suggestion... turn on WPA encryption and use a VPN or (at least) HTTPS if you're using a hotspot. You know... the only things that will actually protect your data, rather than obfuscate it?
I mean, to their credit, the list isn't inherently bad. Hide or disable your identifier, don't use public hot-spots, be careful, etc. However, it leaves the user with a false sense of security. If a user followed every suggestion in that list, Google could just as easily sniff every byte of traffic. Talk about inept and ineffective.
This is a fantastic and welcome suite of upgrades, bugfixes, optimizations, and changes. Thank you KDE team!
For those who have forsworn KDE due to bad experiences with the 4.x line, let this be a formal request to reconsider your aversion. The initial KDE 4 releases were unusable, and this has greatly hurt their image and reputation. However, as of KDE SC 4.5, it is ready to replace other desktop environments. I promise you, to both GNOME users and KDE3.5 clingers: it is worth your time to try KDE SC 4.5 (or 4.6), and you will not be disappointed.
For a bit of history, even the KDE team understood that the early KDE4 releases were not suitable for most users. They urged those who wanted feature-complete desktops to avoid it. Much to their own disappointment, major distributions like Ubuntu and OpenSUSE rushed to adopt it and the result was... well, mass disappointment. The first release recommended by the KDE team as a KDE3.5 replacement was 4.2, which was still generally lacking but worlds better than its predecessors. Every release contained more polish, and 4.5 was (in my opinion) the milestone of a release that fully eclipses KDE 3.5 and leaves no doubt about the vision of the KDE team.
So nice redesign in general, although there is too much whitespace (trim it down a bit!). Anyway, is there any chance to get a mobile page added onto this? Something that's specifically tailored for a mobile device's screen size and touchscreen interface? I've always found it bulky and troublesome to navigate Slashdot with my mobile device, and this redesign is, unfortunately, no exception.
Agreed, but this part of the article had me intrigued:
It wasn't a totally perfect solution. Most specifically, ISPs can force a downgrade of https to http, but Sullivan said that Facebook had not seen that happen.
I do not know the ins and outs of internet routing well enough to understand this, but I was alarmed by it. Does anyone with more technical expertise in the area have any insight?
I think it's simple: Facebook allows HTTP logins, but defaults to HTTPS. The ISP could respond to the initial HTTPS request with a redirect to the regular HTTP version.
The problem is that sites would be justified (imo) to then not offer you service based on this.
“We support this site with ad revenue. Tracking is part of that. No Tracking, no service”.
This is fine really. People aren’t entitled to web content. In many cases your privacy is what you are trading for it, and you should be made aware of this and have the option to decline. This kind of header (and possibly others like it) would let you specify in what you are ok with, and let a site then decide whether it’s enough to grant you access.
The problem is that people don’t like this... they want the privacy _and_ the content.. so people would probably just go back to using ad-blockers and cookie deleters as soon as they start getting rejected access messages.
Not necessarily. By adding support for the header, an opportunity is created to write into law that advertisers (and content providers) must not track requests with this header present. Failure to do so can be penalized similarly to the "do not call" registry, with fines and/or jailtime. However, people who avoid advertisements via ad-blocking software will not be beneficiaries of such a law, and, accordingly, will never have a legally-binding guarantee that they aren't being tracked.
Like you said, advertising-based sites will likely deny service, serve a lesser ("lite") version of their site, and maybe offer an ad-free membership option that can be purchased. I agree with you; this is understandable, since they are ad-revenue sites.
Users will have three choices:
Omit the header ads and be tracked, but have access to ad-supported sites.
Include the header, be comfortable knowing you are not being tracked, have a legal avenue to pursue if you are, and be denied access to ad-supported sites.
Omit the header, use ad-blocking software, and be tracked while avoiding the ugly ads without any legal avenue to pursue the tracking.
This benefits both the consumer, who can now clearly state their intention and have it be legally binding. It also protects the content provider and advertisers; they can read the user's intent and know for sure whether or not their tracking and advertisements are legal, and now they have an option to offer a reasonable path to a paywalled service, as the user has to explicitly acknowledge the ad-supported nature of the site. For now, I feel that this is a great idea, and (for what it's worth) I'd likely choose the omit/ad-block path.
In Florian's paper, he points these out as Sun PROPRIETARY / CONFIDENTIAL. However, it looks like several of the sources come from Sun's mmademo, linked here. In this rendition of the document, each source file's license is a permissive one by Sun (i.e., not proprietary / confidential).
The ones from microedition seem to be mentioned elsewhere under GPL.
Some sources seem to come from here, where some of the files (e.g., Control.java) have the proprietary markings, but these are interfaces. Control, for example, is an empty interface. Not sure if that affects anything.
I'm not qualified to make any sense out of this, but it seems like several of the sources Florian mentions are actually GPL'd sources with incorrect headers. There are a few trivial ones that (in the source I found) seem to be correctly marked proprietary. As much as I admire Florian's ability to grep, I think he's just found an error in some headers, not actual violations.
Let's see, there are two possibilities that come to mind since this was done in the proximity of the female Icelandic MP with connection to wikileaks:
The member of parliament who is a friend of wikileaks is in on this and wikileaks conducted the spying as is being ignorantly claimed
Agents on behalf of the US government conducted this in order to spy on the icelandic MP and others nearby because of her connection to wikileaks
Obviously we can throw out #1 because it does not at all fit with wikileaks modus operandi and cannot be carried out by their infrastructure. They're set up to anonymously accept documents and disseminate them, they're not spies. Moreover the icelandic MP in question would be risking much to do this only to access documents she probably already has access to.
So #2 becomes the most obvious culprit.
Or, of course, agents of any country that stands to gain from espionage conducted this in order to spy on someone in Iceland.
I'm thinking this through and thinking of my android-based device. For anything to gain access like this wouldn't the user need to be root?
Or can the app simply request permission?
(Disclaimer: I'm root and have cyanogen on my phone.)
The article says the application requests the following permissions:
Read Phone State and Identity: Used to know when your phone is calling
Your Personal Information: Not really used in the attack.
Hardware Controls (probably specifically microphone): Lets the application record audio
There's an additional app that requests Network Capabilities; it's used to relay the data. Since the original application doesn't request those capabilities, it's less obvious (although now a second application has to be installed).
Basically, the application masquerades as an overly-permissive "voice recorder". It registers to receive notifications when the "phone state" changes, and when you place a call it starts recording. It processes the audio and pulls out voice and touch-tone number sounds. It then passes that information to the "Deliverer" application, which forwards it to the bad guy. Two applications written by the same developer can share data, so they probably use that channel.
The scenario is that a user will install the recorder app because they want a voice recorder, and will install the "Deliverer" app for some unrelated reason. Neither app's permissions set off any warning bells, but, together, they can steal your data.
So no, no rooting necessary. Goes to underline the general idea - given any security fence and enough time to understand it, someone will find a way around it. It's not particularly creative or innovative - just one of those proofs-of-concept of the obvious that will get media attention. Android's permissions are a nice heads-up to the user, but you really need to know and trust the publisher before you give any of the more deadly set of permissions (e.g., hardware controls, network communication) to an app.
Slashdot Mirror
"Cell phones will be automatically registered at cell towers as soon as they are switched on." ... err, as they usually do? Since otherwise, how would the cell company know how to route a call for you?
Of course TFA is in Chinese, and I don't know what it really says, but yeah, the very design of the cell network allows for such tracking, and there's a lot of potential for abuse there, whichever government does it.
I guess this is in response to the Arab protests, if you as the authority can see where people are gathered/gathering, you know where to send the skull-crackers to.
Oh, and logging individuals would make it easier to see which people (phones) show up at these things regularly, for whatever reason, so we can crack their skulls too!
I wonder what sort of techniques can be used to fight this; multiple phones (useless since afaik you need an ID card to get a SIM card), leave your phone at home, go to "airplane mode" at a random time before the planned demo? Should the protesters buy walkie-talkies and tune to xy frequency? (The police would then just skull-crack anyone caught with a walkie-talkie).
There are still ways for critical people to remain safely anonymous under this circumstance. For example:
That or China could legitimately be using this to monitor traffic density. I mean, traffic is a huge problem in several areas, and knowing the migration paths and times of citizens would be invaluable to devising an ideal solution.
A custom C library doesn't matter, if its 'native code' the C library is irrelevant as you're producing x86 machine code in the final NCI file.
To be safe, they essentially need to run it in a virtual machine without access outside the VM.
x86 code verifiers are about as useful as enabling heuristics detection in a virus scanners, the only thing they catch is something thats already more or less been seen in the exact same sort of form.
Maybe you should read up a bit on it before you make stupid comments. Their code verifier doesn't scan for known attacks (antivirus-style). Instead, Google has identified a subset of instructions which, when run in a specific sandboxed environment, eliminate the ability for the code to perform malicious activities. One pruning of the instruction set removes instructions that enable code to hide from the verifier (alignment requirements, removal of register jumps, etc.). The second constrains the instruction set, removing things like direct system calls, far jumps, etc.
The system also uses x86 segmentation capabilities to enforce a specific sandboxed execution environment. Doing this implicitly limits the scope of the code's branching and allows the verifier to make some critical assumptions that validate the assembly.
Rather than reproduce the paper, you should check out the link that I provided. Regardless, to say that the code verifier is not adequate is just foolish. The papers clearly explain, using logical proofs, how the various constraints enforced by the NaCl runtime, sandboxes, and code verifier are enforceable and provide reliable security. The "custom C library" is used in conjunction with the constraints to retain a general usefulness, facilitate inter-process communication (the primary mechanism of action), and work within NaCl constraints to perform higher-level operations like system calls.
...thanks to the Apple fan-boys.
I bought one. I'm not an Apple fanboy. This is, in fact, the second (alongside a third-generation iPod) Apple product that I've ever purchased. I've generally been rather anti-Apple, namely due to their shoddy Linux support (remembering early iPod days), their gross bloatware that is Windows iTunes (slash Safari, slash QuickTime, slash who the fuck knows), and my experiences working with Objective C and the Cocoa APIs professionally some early OSX builds.
That said, I went laptop shopping and, after soliciting several opinions, reading dozens of reviews, and looking at numerous potential models, I decided to go with the MBP. It was the only laptop (that I could find) that matched my criteria in terms of weight, battery life, touchpad functionality and size (was a huge selling point), keyboard layout, screen resolution, and power. I intend to use Boot Camp to dual-boot a Kubuntu distribution and will likely give both OSX and Kubuntu equal face-time. I also hope to contribute to various Linux drivers and software tweaks that target MBP hardware (camera, touchpad, etc.).
That said, let's talk Apple fanbois. I will use my experience with this device as almost my sole judge of my opinion of Apple software. How it boots, how it operates, and my experience with the UI will determine whether or not I become an Apple fanboy. I sincerely hope I do; from what I've seen, Apple is one of the few companies that is actually innovating in terms of user experience (I'll cite every music player, laptop, phone, and window manager that is playing catch-up; I understand things go deeper, Superkaramba, etc., but largely most modern composed UIs were first fully-realized by Apple). I really hope that Apple is as good as it seems on paper.
Now, granted, Apple has a negative reputation for several things. Overpriced hardware is one, for sure, but the one that really bothers me is their gatekeeper role in device software. I've always written this off because part of me definitely sympathizes with their perspective on users - that a device that "just works" is more valuable than an open platform. This definitely reflects what I've observed in the amateur computer user base, and is why I have an Android phone (and will never own an iPhone). If they had similar lockdowns of their notebooks, I'd feel similarly.
What Apple products need, I suspect, is a thriving open-source community, and looking at the thousands of Apple-targeting OSS projects out there, this seems to be the case. Just as with Windows, and MS-DOS before it, the open-source community needs to thrive in the face of adversity, provide compelling alternatives, and change both the foreground and background of the operating system - in other words, do what it does best.
And the point is that you have no say in the matter. You must "sit tight" and wait on Google to do something to save your valuable data. Yet, for some reason, you perceive a list of unanswered questions as a strength of the cloud, as if helplessly wondering what Google is going to do to save the data you've stored in its free service is an advantageous position to be in.
I do not perceive the strength of the cloud as a list of unanswered questions. I simply don't perceive a regular system error as an inherent cloud weakness. The unanswered questions, once answered, will determine whether or not this particular cloud is strong or weak. That a system has failed and that an error has occurred is not a statement on cloud-based services as a whole, but rather on Google as a cloud provider.
Anything you're comfortable handing to a local IT department could arguably have a cloud presence that is just as strong. The only difference is who's staffing the systems. Google's situation is very similar to the situation of any service provider, be it a cloud, an outsourced IT department, an in-house IT department, or yourself. If you don't believe that Google will sincerely do everything in their power to maintain their systems and recover from such failures, then so be it; don't use their services.
If you happen to be the type that simply considers anything they can't themselves fix to be inferior, then there's really no argument to be had. Have fun running everything.
Everybody knows that backups are good, cloud or no cloud. Everybody knows that things go wrong, cloud or no cloud.
The trouble is, that while you are correct, that the general populous makes the assumption that because you are in the cloud that there are no problems and that backups are required. I have had this argument myself before that the cloud is not perfect. And while you are at it throw in the additional fact that if the company hosting your cloud decides it is no longer profitable, then you better have a backup for that reason as well.
I agree, but the same population also makes the assumption that data is safe to begin with. This is the population that doesn't back up their local files, and likely can't properly recover them even if they did. This population likes to offload the problem of data or system failure to another technology - an external hard drive with backup software, an IT administrator, a cloud, etc.
To such a population, the possibility that the cloud might recover from failure is greater than the default solution (no backup); add the strength and competence of a company like Google into the mix and it'll likely surpass the other alternatives as well. I suspect the general population has a much better chance at overall data integrity and disaster recovery in a well-managed cloud than with any other solution.
For the rest of us, perhaps this is a timely reminder to backup our data and be less trusting of the cloud.
Okay, Slashdot, this is getting tiring. Every time a major cloud service fails, the inevitable "re-evaluate your trust in the cloud" mantra is mindlessly invoked. Everybody knows that backups are good, cloud or no cloud. Everybody knows that things go wrong, cloud or no cloud. So what's the real value-added to calling out cloud services every time something fails?
The interesting question is how the disaster is addressed. Will Google recover the data? Will it be quick? Seamless? If so, then the real lesson here isn't the weakness of the cloud, but rather its strength. Anything can go wrong with any system, but maybe Google's well-run cloud can handle the problem with minimal incidence.
So, Slashdot, rather than spouting off a thoughtless, ominous warning on every "something breaks in a cloud" story, how about you sit tight and see how this resolves?
I see this a lot in politics these days: educated, intelligent journalists lashing out and saying anyone who doesn't agree with their political opinions must not be a member of the human race. And here's one who thinks that it's OK to call for deaths just because she's frustrated.
There's a critical difference between a satirical call for death and an actual death threat. Death itself is a powerful subject, and it can be used quite aptly to evoke far more sentiment than straight murderous rampage. In this case, she wasn't stating her intent to kill Berlusconi, nor was she attempting to rally others to do the same. Rather, she was expressing her rage and frustration at him, which is well within (at least American) bounds of free speech.
This seizure wasn't made out of fear and concern for Berlusconi's wellbeing. This is textbook abuse of law for the purpose of silencing opposition.
America has the same thing, Sarah Palin's calls for violence incited her followers and real people died.
This is a really stupid example. Maybe read a little into things before echoing the political impulse. As outrageous and annoying as Palin is, there is no good reason to suspect she had anything to do with the shootings.
What is terrorism. It is through fear to change peoples behaviour or politics or whatever. If someone blows a bomb to kill plenty of people that is not terrorrism. If the another person blows a bomb to make people not buy windows, then that is terrorism.
If someone fears the tooth fairy and by showing pictures of the tooth fairy, that person can be averted from a certain tooth paste, then that is terrorism, no violence needed.
You seem to have a grossly-simplified take on the matter. While the definition of terrorism is (understandably) difficult to state, legally-accepted definitions range from straight-up "harming large amounts of people" to coercion. Your example suggests you see terrorism as identical to Coercion, which is one naive take on the matter. However, all of your examples fall under one legal definition of terrorism or another.
Here are a few definitions from the Wikipedia article:
So is Anonymous (or, rather, are those who have operated under that pseudonym) a terrorist organization? Core to all of these seem to be violent acts by non-state actors against noncombatants. It seems to me that Anonymous actors and targets match, so the real question is whether or not Anonymous' actions qualify as violent acts.
While some things (like hacking websites) seem more akin to vandalism, in that they are not intended to cause harm, others, like DDoS attacks, could very well be the Internet equivalent of a violent attack. However, putting a DDoS attack against Mastercard on the same level as a subway bombing so grossly trivializes the latter. I think, rather than attempt to pervert words by drawing Internet parallels, the Anonymous actors should be regarded as persons sympathetic to terrorist ideals, but not actually terrorists. Idealistic Internet Vandals seems more appropriate.
It should go without saying that any technical word used by the average layman likely has no sophisticated technical meaning.
Significantly reduces Bing's legitimacy? Quite the contrary. It shows that their search bar is doing exactly what it is intended to do, track its users and see what content they find the most useful. If they enter a search term in any search engine, including Bing, it surely is getting tracked and then automatically updated in Bing's system. This shows that they have a great (and functioning) mechanism for tracking relevance among their users.
Quote the whole phrase. If Bing uses Google, it's less legitimate as an innovative search provider. Obviously, using (and improving upon) someone else's technology doesn't reduce the usefulness of your own technology. It just makes you a fork.
There are also many other types of situations where it a citation is not ethically required or even permitted. Citation is not permitted in this case, because it would violate Google's trademark.
Saying "we use Google" doesn't violate Google's trademark at all. Saying "we are Google", on the other hand, does. Big difference.
It seems like this is publicly available information. Were there any stipulations, even if informal, on how that information could be used?
Nobody's saying this is illegal (... yet?). Rather, it significantly reduces Bing's legitimacy as an innovative search technology and as a competitor to Google. In literature, using someone else's work requires a citation. For all ethical purposes, Bing should be labelled "powered by Google".
It's nice, although not as quick as all that on my machine.
But what does this demonstrate? Anyone interested knows you can display arbitrary graphics using HTML5 canvas. Anyone with any sense knows you can calculate a view of a Julia set in Javascript. Add the two together, and it's inevitable that this demo would be possible.
Now, how about using Web sockets to set up some kind of P2P network whereby if someone else is viewing the same region as you are, your machines collaborate on the calculations...
That and the Mandelbrot / Julia sets are awesome to explore, and they can now be explored from your browser with no dependencies. Something doesn't have to demonstrate a new or innovative use of technology to be cool and worthwhile.
But this demo not only performs a significant number of floating-point calculations. It also utilizes several system cores, demonstrating (once again) the viability of an HTML5-equipped browser as an application platform.
that's not necessarily a lesser problem.
chipsets are typically soldered onto motherboards, while CPUs are clipped into sockets.
in order to install a free-replacement CPU, you flip a clip and put in the new part. 5-10 minutes for an inexperienced tech (60 seconds for a l33t h4xx0r whose system is never truly buttoned-up), and one new part to check out.
in order to install a free-replacement chipset, you replace your motherboard. a couple of hours of unplugging, unscrewing, unpacking, re-screwing, chasing screws that fell off the desk, plugging back in, double-checking the plugging-in, going online to find a representative picture to be sure you put the memory in the optimal slots, and closing up the case. and then you have a hundred new parts to shake out.
Don't get me wrong, I don't think it's a lesser problem. I got the tone from the OP that he was confused how a CPU issue could cause such a specific and isolated problem with SATA, so I was pointing out how the problem wasn't with the Sandy Bridge CPU, but rather with the supporting chipset.
Obviously, silicon bugs happen, barely anything makes it out of the fab without an 'errata' list as long as your leg; but the "may gradually degrade over time" part kind of freaks me out. If it were a "due to a design error, setting register xyz to 0xDEADBEEF causes Serious Badness, chipset drivers are being patched to Never Do That on rev.1 chipsets and future chipsets will be amended" that would be unfortunate; but so it goes. Fully deterministic errors, like the classic division bug, may be problematic; in some cases bad enough to qualify the product as just plain defective; but once known they can be mitigated by not stepping on them. Something that "sometimes" "gradually decreases" performance, on a bus with error correction, though, sounds a lot like a physical problem where some sort of silicon/electrical issue causes error rates to increase and thus retries/corrections to increase in frequency, and user-visible performance to go down. That makes me nervous. It sounds less like a deterministic error problem and more like a certain physical components are actually degrading much faster than expected problem... Can anybody think of an explanation for how a hardware bug would cause behavior that gradually changes over time(in a manner that couldn't be dealt with with a driver update) that doesn't involve the alarming possibility of gradually increasing error rates and/or early death of onboard SATA ports?
Well, the flaw is with the Sandy Bridge chipset that accompanies the CPU, so it's not with the CPU itself. The http://en.wikipedia.org/wiki/Sandy_Bridge#Architecture includes, among other things, the IO and memory controller hub components, which control (between them) DMA and the actual SATA controller hardware and some of the relevant busses. I assume the problem is somewhere in there, and is hardware-related (i.e., not firmware-upgradeable).
A separate Jepsen press release suggested some of the blame for the privacy offenses laid with Google's victims, who were advised to 'turn off your wireless network when you know you won't use it' to thwart those who 'may be watching your Internet activity without your knowledge.
So from the actual link:
The consortium recommends:
Are you fucking kidding me? After all of this, the court case, the hearing, a formal consortium omits the single most important and critical suggestion... turn on WPA encryption and use a VPN or (at least) HTTPS if you're using a hotspot. You know ... the only things that will actually protect your data, rather than obfuscate it?
I mean, to their credit, the list isn't inherently bad. Hide or disable your identifier, don't use public hot-spots, be careful, etc. However, it leaves the user with a false sense of security. If a user followed every suggestion in that list, Google could just as easily sniff every byte of traffic. Talk about inept and ineffective.
This is a fantastic and welcome suite of upgrades, bugfixes, optimizations, and changes. Thank you KDE team!
For those who have forsworn KDE due to bad experiences with the 4.x line, let this be a formal request to reconsider your aversion. The initial KDE 4 releases were unusable, and this has greatly hurt their image and reputation. However, as of KDE SC 4.5, it is ready to replace other desktop environments. I promise you, to both GNOME users and KDE3.5 clingers: it is worth your time to try KDE SC 4.5 (or 4.6), and you will not be disappointed.
For a bit of history, even the KDE team understood that the early KDE4 releases were not suitable for most users. They urged those who wanted feature-complete desktops to avoid it. Much to their own disappointment, major distributions like Ubuntu and OpenSUSE rushed to adopt it and the result was ... well, mass disappointment. The first release recommended by the KDE team as a KDE3.5 replacement was 4.2, which was still generally lacking but worlds better than its predecessors. Every release contained more polish, and 4.5 was (in my opinion) the milestone of a release that fully eclipses KDE 3.5 and leaves no doubt about the vision of the KDE team.
Only if the driver is an American. ;-)
You know, mainland America ain't so far ahead of the curve. According to that list, if it's built by Germans, it'll have no trouble handle American asses.
(Not getting uppity. I thought your post was funny and it inspired me to look up numbers, so I'm just completing the circle)
Not so much considering he gets to play with Lego bricks all day long. It may be a waste of his talent, but hell, who cares if he enjoys it.
How much do you earn and is your job as entertaining as his will be?
I'd quit my (better payed) job not thinking twice if I get offered that position.
Here's a thought: get an engineering job, make three times that much in one year, and then take the next two years off to play with Legos.
So nice redesign in general, although there is too much whitespace (trim it down a bit!). Anyway, is there any chance to get a mobile page added onto this? Something that's specifically tailored for a mobile device's screen size and touchscreen interface? I've always found it bulky and troublesome to navigate Slashdot with my mobile device, and this redesign is, unfortunately, no exception.
Agreed, but this part of the article had me intrigued:
I do not know the ins and outs of internet routing well enough to understand this, but I was alarmed by it. Does anyone with more technical expertise in the area have any insight?
I think it's simple: Facebook allows HTTP logins, but defaults to HTTPS. The ISP could respond to the initial HTTPS request with a redirect to the regular HTTP version.
The problem is that sites would be justified (imo) to then not offer you service based on this.
“We support this site with ad revenue. Tracking is part of that. No Tracking, no service”.
This is fine really. People aren’t entitled to web content. In many cases your privacy is what you are trading for it, and you should be made aware of this and have the option to decline. This kind of header (and possibly others like it) would let you specify in what you are ok with, and let a site then decide whether it’s enough to grant you access.
The problem is that people don’t like this... they want the privacy _and_ the content.. so people would probably just go back to using ad-blockers and cookie deleters as soon as they start getting rejected access messages.
Not necessarily. By adding support for the header, an opportunity is created to write into law that advertisers (and content providers) must not track requests with this header present. Failure to do so can be penalized similarly to the "do not call" registry, with fines and/or jailtime. However, people who avoid advertisements via ad-blocking software will not be beneficiaries of such a law, and, accordingly, will never have a legally-binding guarantee that they aren't being tracked.
Like you said, advertising-based sites will likely deny service, serve a lesser ("lite") version of their site, and maybe offer an ad-free membership option that can be purchased. I agree with you; this is understandable, since they are ad-revenue sites.
Users will have three choices:
This benefits both the consumer, who can now clearly state their intention and have it be legally binding. It also protects the content provider and advertisers; they can read the user's intent and know for sure whether or not their tracking and advertisements are legal, and now they have an option to offer a reasonable path to a paywalled service, as the user has to explicitly acknowledge the ad-supported nature of the site. For now, I feel that this is a great idea, and (for what it's worth) I'd likely choose the omit/ad-block path.
In Florian's paper, he points these out as Sun PROPRIETARY / CONFIDENTIAL. However, it looks like several of the sources come from Sun's mmademo, linked here. In this rendition of the document, each source file's license is a permissive one by Sun (i.e., not proprietary / confidential).
The ones from microedition seem to be mentioned elsewhere under GPL.
Some sources seem to come from here, where some of the files (e.g., Control.java) have the proprietary markings, but these are interfaces. Control, for example, is an empty interface. Not sure if that affects anything.
I'm not qualified to make any sense out of this, but it seems like several of the sources Florian mentions are actually GPL'd sources with incorrect headers. There are a few trivial ones that (in the source I found) seem to be correctly marked proprietary. As much as I admire Florian's ability to grep, I think he's just found an error in some headers, not actual violations.
Let's see, there are two possibilities that come to mind since this was done in the proximity of the female Icelandic MP with connection to wikileaks:
Obviously we can throw out #1 because it does not at all fit with wikileaks modus operandi and cannot be carried out by their infrastructure. They're set up to anonymously accept documents and disseminate them, they're not spies. Moreover the icelandic MP in question would be risking much to do this only to access documents she probably already has access to.
So #2 becomes the most obvious culprit.
Or, of course, agents of any country that stands to gain from espionage conducted this in order to spy on someone in Iceland.
I'm thinking this through and thinking of my android-based device. For anything to gain access like this wouldn't the user need to be root? Or can the app simply request permission? (Disclaimer: I'm root and have cyanogen on my phone.)
The article says the application requests the following permissions:
There's an additional app that requests Network Capabilities; it's used to relay the data. Since the original application doesn't request those capabilities, it's less obvious (although now a second application has to be installed).
Basically, the application masquerades as an overly-permissive "voice recorder". It registers to receive notifications when the "phone state" changes, and when you place a call it starts recording. It processes the audio and pulls out voice and touch-tone number sounds. It then passes that information to the "Deliverer" application, which forwards it to the bad guy. Two applications written by the same developer can share data, so they probably use that channel.
The scenario is that a user will install the recorder app because they want a voice recorder, and will install the "Deliverer" app for some unrelated reason. Neither app's permissions set off any warning bells, but, together, they can steal your data.
So no, no rooting necessary. Goes to underline the general idea - given any security fence and enough time to understand it, someone will find a way around it. It's not particularly creative or innovative - just one of those proofs-of-concept of the obvious that will get media attention. Android's permissions are a nice heads-up to the user, but you really need to know and trust the publisher before you give any of the more deadly set of permissions (e.g., hardware controls, network communication) to an app.