What sensible people actually propose is to eliminate the fat side channels that are so plump and juicy that anyone who comes along could exploit them with incidental nonchalance.
Would you believe there are people at Firefox/Chrome/Safari/Edge that are doing this right now?:-)
What's more, remember that each such side channel is additive. So you don't need to find a particular fat one in order to whittle at privacy.
The threads can not be eliminated. But the weaver can be forced to possess 300 different lock picks, each and every one sourced from the Ruhr valley.
Of course, what you mean is that one person has to figure out and publish a paper, then the rest of the plebs just do an npm install.
At the end of the day if the user has full control over their device (which they don't with Apple), there isn't anything that advertisers can attempt to do that the user can't thwart in some way.
Add in a VPN or some other service that obfuscates your IP / location and there's not a lot that they can do.
True in theory.
Devilishly difficult to implement in practice, because what you are proposing is the elimination of all side channel information leakage from the browser to the web host. And all those tiny bits of information that can add up (user-agents, DOM support) to a pretty good identifier. Check out the EFF's Panopticlick site, which details all the tiny information leakages and sums them up.
Add to that canvas fingerprinting and other skullduggery, and even with full control over a device, it's an uphill battle to thwart all the ways an advertiser can assign you a unique stable identifier.
YOU DO NOT ENDANGER OTHERS IF YOU ARE NOT VACCINATED. You endanger yourself; it's to train your immune system. Yes, you could carry and spread it to other people WHO ARE NOT VACCINATED.
Including INFANTS who are TOO YOUNG to be vaccinated and might not live to see it because of your selfish dumb ass.
Only a privileged process may bind sockets to listening ports, or read privileged files
OK, but those sockets can be bound and those files read before dropping privileges. Those things should be considered fixed for the lifetime of the process anyway.
meaning absent a privileged master process, you have to completely respawn the process
In order to change config? Is this really a proposal that we need to incur increased security surface of a root-process for the trivial convenience of being able to change the configuration of a daemon on the fly instead of just reloading it?
I don't see how punting the secure privilege-crossing processing up a layer (to the kernel) is any more pragmatic.
The principle of least privilege is real. There has to be security surface area in the kernel, no need to just add to the attack surface unless it's absolutely necessary for a critical function.
And why didn't the Apache shim call setuid to remove its root privileges after doing what it needed to do?
I get that IPC across privilege boundaries is hard. You can either try hard to do it right, or you can take the more pragmatic approach of not doing it at all.
Common sense would indicate that in that scenario you either
1. Get the socket as early as possible in startup then setuid(2) yourself to a user with lower privileges (and chroot yourself, while you are at it) before answering any requests
2. Failing that, run on a high numbered port and have iptables forward you traffic from 80, which is a specific instance of the more general strategy: run as little code as possible at high privilege
What's not an answer is "run the actual process as root while serving user requests". It's shocking that this is even considered remotely like a possible solution.
What's doubly galling is that there is a loooong unix history of applications that require far more intrusive privileges using both or these techniques -- either getting what they need and immediately dropping to the position of least privilege or using a small shim or utility that runs in a high-privileged space and communicates with the rest of the service via IPC. So it's not like they couldn't draw on those examples or literally just copy-pasta DJB's code.
What's triply galling is that the fix doesn't actually appear to mentioned fixing any of this, just patching this one vulnerability.
2) Sorting adds costs. Pre-sorting reduces labor, error rates, and significantly reduces contamination and mixing.
How can pre-sorting (doing the sorting before collection rather than after) reduce labor? If anything, post-collection there is a major economy of scale at having dedicated equipment (magnets, blowers) that's a lot more efficient than sorting by hand.
What I think people mean is that pre-sorting reduces labor costs at the recycler by offloading it to everyone else. Which those people are free to decline. So unless you figure you can convince them (by reason, or threat, or who knows what) to do it, it just ain't gonna happen.
I don't get it -- he never paid a lawyer (until he sued in civil court) because it never even got to pre-trial state, let alone to trial. He didn't even have to post bail or bond because he was out on his own recognizance.
I don't get it -- the police suspected him of a crime and booked him in and set a date for him to have a trial in a court of law. If this is "guilty until proven innocent" then it's not possible to ever book/charge anyone for anything because you'd never know they were guilty until the trial and you'd never get to the trial without the charge.
From the sounds of it, the police had a shitty case, the shitty case fell apart before it even went to trial. No one was found guilty of anything, nor did the guy spend even a single minute in jail.
One thing I love about my current job is that everyone takes this rule almost 100% seriously. You are almost forbidden to do anything while you have a review pending on you.
The reasons are fairly obvious -- reviews are a blocking operation. Sure, the developer can go work on something else, but if he's got a chain of dependencies to work through, things get hairy if he gets too far ahead of the reviewers.
Other benefits are more subtle. First, it encourages everyone to carefully pre-review, because they know that sending it up will interrupt everyone and they don't want to do so trivially. The second major benefit is that the longer things are pending, the greater the chances of merge conflicts, and even with the best of tools, 3-way merging is the enemy.
Of course, we aren't robots. And a huge change may take a week to read. But it's a good general default rule that you shouldn't be writing code or investigating bug reports if you've got a patch waiting on you.
I own my computer and it will do what I tell it to do.
You aren't giving others' preferences the same weight that you are giving your own. They own their computers same as you own yours and hence they have every right to chose "deal with this for me" as you do to fiddle around and set things exactly the way you like them.
I get that you disagree with their choices, much as they disagree with your judgment that it's useful to spend all this time futzing with an appliance.
So long as Yelp must remove reviews that were ruled to be defamatory. If they don't, then S230 needs to be reformed because no platform should have a right to keep defamatory reviews up after they've been ruled as such in court.
Agreed in principle.
That said, there is an interesting (read: sneaky) set of cases around this principle.
Plaintiff goes to "reputation management" company to remove bad reviews
Reputation management company recruits someone to be the defendant
RMC sues the 'defendant', which then admits to making the post (they didn't) and that it was defamatory (maybe it was) and settles for a small sum. This suit, however, isn't the point
RMC goes to Google/Bing/Yelp with the court order now that it has been "ruled defamatory". By policy, many will remove or de-index it.
For one, the human capacity for ingenuity is astounding. Using a straw defendant to get a court ruling to satisfy Google's policy of "we will remove anything a court has found defamatory" is pretty next-level thinking. The courts are happy to vacate those orders when someone shows up with proof of the fraud (and more, some of the companies were fined $100K or so), but that requires someone to notice and investigate. Prosecutors sometimes catch wind too and can bring charges, but again that requires it being brought to their attention. Legal gadflies might do this pro-bono (and to rightfully troll the RMCs), but that's hardly a foolproof system.
Ultimately, I don't have much of a good answer. Yes, Google and Yelp should de-index material when it has been found defamatory in a fair court case. How Google and Yelp are supposed to assess whether the court order is the product of fraud or not, when they get thousands of them is beyond me . . .
You might consider, what does the RIL interface with? If you track it down from userland to the kernel you'll see it's communicating with the cellular modem, either over some actual physical interface like USB or a intra-SOC shared memory bus.
Somewhere in the heart of Android, theres a Linux kernel, still under the GPL, bleeding out for the loss of all it was supposed represent.
And next to the core running Linux is a cellular modem, running some wonderful proprietary "OS" on a DSP. You don't really think they were running LTE signal processing on a vanilla ARM under Linux, right?
The GPL doesn't mean that software running on a completely separate core (or in some cases, a completely separate physical semiconductor) inherits the GPL just because Linux talks to it via some driver.
[ There are a few OSS-friendly cellular modems, but they are a few generations behind on speed, power and certifications. ]
The galaxy S3 was launched in 2012. They are planning on pulling support in 2021 -- that seems like they have supported it above and beyond the expectation of 5-6 years.
It's superficial because they are getting gains in battery life by removing functionality rather than actually improving the capacity or efficiency of the phone. That is, it connotes an improvement in the superficial appearance of things -- looking better rather than being better.
Widevine exists only to satisfy contract demands by content providers to protect the streams. Lot$ spent (and passed on to the consumer) to do nothing.
It might be lots of money in absolute terms, but it's peanuts on the scale of Netflix. Since they are a public company, we can look at their financial filings and take a look. The entirely of R&D spending is less than 10% of their total operating expenses, which is dominated by buying/creating content and continuing operating expenses (servers, bandwidth). Then there's marketing, and only below that is R&D. Even assuming pessimistically that a whopping 5% of all R&D spending related to DRM (which is crazy), that still amounts to a half percent of total expenses. Dividing it over the subscriber base makes it about a $0.50/yr charge.
I'm not saying it's necessarily money well spent (although if the content owners require it, you should just roll it into the cost of paying them rather than put it in R&D) but it's really not a ton of money. They probably spend more on one failed new series than the total spent on all DRM related R&D activities for a decade.
Slashdot Mirror
Would you believe there are people at Firefox/Chrome/Safari/Edge that are doing this right now? :-)
What's more, remember that each such side channel is additive. So you don't need to find a particular fat one in order to whittle at privacy.
Of course, what you mean is that one person has to figure out and publish a paper, then the rest of the plebs just do an npm install.
True in theory.
Devilishly difficult to implement in practice, because what you are proposing is the elimination of all side channel information leakage from the browser to the web host. And all those tiny bits of information that can add up (user-agents, DOM support) to a pretty good identifier. Check out the EFF's Panopticlick site, which details all the tiny information leakages and sums them up.
Add to that canvas fingerprinting and other skullduggery, and even with full control over a device, it's an uphill battle to thwart all the ways an advertiser can assign you a unique stable identifier.
Including INFANTS who are TOO YOUNG to be vaccinated and might not live to see it because of your selfish dumb ass.
OK, but those sockets can be bound and those files read before dropping privileges. Those things should be considered fixed for the lifetime of the process anyway.
In order to change config? Is this really a proposal that we need to incur increased security surface of a root-process for the trivial convenience of being able to change the configuration of a daemon on the fly instead of just reloading it?
The principle of least privilege is real. There has to be security surface area in the kernel, no need to just add to the attack surface unless it's absolutely necessary for a critical function.
And why didn't the Apache shim call setuid to remove its root privileges after doing what it needed to do?
I get that IPC across privilege boundaries is hard. You can either try hard to do it right, or you can take the more pragmatic approach of not doing it at all.
Common sense would indicate that in that scenario you either
What's not an answer is "run the actual process as root while serving user requests". It's shocking that this is even considered remotely like a possible solution.
What's doubly galling is that there is a loooong unix history of applications that require far more intrusive privileges using both or these techniques -- either getting what they need and immediately dropping to the position of least privilege or using a small shim or utility that runs in a high-privileged space and communicates with the rest of the service via IPC. So it's not like they couldn't draw on those examples or literally just copy-pasta DJB's code.
What's triply galling is that the fix doesn't actually appear to mentioned fixing any of this, just patching this one vulnerability.
Because it was easier to write a sane language and a transpiler than it is to fix the recursive dumpster fire that is JavaScript.
That should really tell us something folks.
How can pre-sorting (doing the sorting before collection rather than after) reduce labor? If anything, post-collection there is a major economy of scale at having dedicated equipment (magnets, blowers) that's a lot more efficient than sorting by hand.
What I think people mean is that pre-sorting reduces labor costs at the recycler by offloading it to everyone else. Which those people are free to decline. So unless you figure you can convince them (by reason, or threat, or who knows what) to do it, it just ain't gonna happen.
I don't get it -- he never paid a lawyer (until he sued in civil court) because it never even got to pre-trial state, let alone to trial. He didn't even have to post bail or bond because he was out on his own recognizance.
I don't get it -- the police suspected him of a crime and booked him in and set a date for him to have a trial in a court of law. If this is "guilty until proven innocent" then it's not possible to ever book/charge anyone for anything because you'd never know they were guilty until the trial and you'd never get to the trial without the charge.
From the sounds of it, the police had a shitty case, the shitty case fell apart before it even went to trial. No one was found guilty of anything, nor did the guy spend even a single minute in jail.
The complement of cloud services is software to run on it, and vice versa. Both sides would benefit by ensuring the other turns into a commodity.
One thing I love about my current job is that everyone takes this rule almost 100% seriously. You are almost forbidden to do anything while you have a review pending on you.
The reasons are fairly obvious -- reviews are a blocking operation. Sure, the developer can go work on something else, but if he's got a chain of dependencies to work through, things get hairy if he gets too far ahead of the reviewers.
Other benefits are more subtle. First, it encourages everyone to carefully pre-review, because they know that sending it up will interrupt everyone and they don't want to do so trivially. The second major benefit is that the longer things are pending, the greater the chances of merge conflicts, and even with the best of tools, 3-way merging is the enemy.
Of course, we aren't robots. And a huge change may take a week to read. But it's a good general default rule that you shouldn't be writing code or investigating bug reports if you've got a patch waiting on you.
You aren't giving others' preferences the same weight that you are giving your own. They own their computers same as you own yours and hence they have every right to chose "deal with this for me" as you do to fiddle around and set things exactly the way you like them.
I get that you disagree with their choices, much as they disagree with your judgment that it's useful to spend all this time futzing with an appliance.
72H, twice a year. I don't think RoundUp is the thing causing kids not to run around outside man.
The instructions on my bottle specifically say not to let your kids and pets play in a treated yard for 72H.
Which, seems actually like a pretty short time. As I understand, one of the major advantages of glyphosate is how fast it's broken down in soil
It actually happened, so there is at least an existence proof that someone had good luck finding a straw defendant.
Facts do be like that sometimes.
Those were also the days of comically bad security vulnerabilities and insanely long times to delivering critical security fixes.
These days, Project Zero gives you a 90 day disclosure window. Stable or not, you are highly incentivized to patch it before it's publicly disclosed.
Agreed in principle. That said, there is an interesting (read: sneaky) set of cases around this principle.
For one, the human capacity for ingenuity is astounding. Using a straw defendant to get a court ruling to satisfy Google's policy of "we will remove anything a court has found defamatory" is pretty next-level thinking. The courts are happy to vacate those orders when someone shows up with proof of the fraud (and more, some of the companies were fined $100K or so), but that requires someone to notice and investigate. Prosecutors sometimes catch wind too and can bring charges, but again that requires it being brought to their attention. Legal gadflies might do this pro-bono (and to rightfully troll the RMCs), but that's hardly a foolproof system. Ultimately, I don't have much of a good answer. Yes, Google and Yelp should de-index material when it has been found defamatory in a fair court case. How Google and Yelp are supposed to assess whether the court order is the product of fraud or not, when they get thousands of them is beyond me . . .
Yes, the RIL -- the Radio Interface Layer.
You might consider, what does the RIL interface with? If you track it down from userland to the kernel you'll see it's communicating with the cellular modem, either over some actual physical interface like USB or a intra-SOC shared memory bus.
And next to the core running Linux is a cellular modem, running some wonderful proprietary "OS" on a DSP. You don't really think they were running LTE signal processing on a vanilla ARM under Linux, right?
The GPL doesn't mean that software running on a completely separate core (or in some cases, a completely separate physical semiconductor) inherits the GPL just because Linux talks to it via some driver.
[ There are a few OSS-friendly cellular modems, but they are a few generations behind on speed, power and certifications. ]
The galaxy S3 was launched in 2012. They are planning on pulling support in 2021 -- that seems like they have supported it above and beyond the expectation of 5-6 years.
Glyphosate is a herbicide, not a pesticide.
It's superficial because they are getting gains in battery life by removing functionality rather than actually improving the capacity or efficiency of the phone. That is, it connotes an improvement in the superficial appearance of things -- looking better rather than being better.
It might be lots of money in absolute terms, but it's peanuts on the scale of Netflix. Since they are a public company, we can look at their financial filings and take a look. The entirely of R&D spending is less than 10% of their total operating expenses, which is dominated by buying/creating content and continuing operating expenses (servers, bandwidth). Then there's marketing, and only below that is R&D. Even assuming pessimistically that a whopping 5% of all R&D spending related to DRM (which is crazy), that still amounts to a half percent of total expenses. Dividing it over the subscriber base makes it about a $0.50/yr charge.
I'm not saying it's necessarily money well spent (although if the content owners require it, you should just roll it into the cost of paying them rather than put it in R&D) but it's really not a ton of money. They probably spend more on one failed new series than the total spent on all DRM related R&D activities for a decade.
So citation to the data collected and analyzed by the experts in a given field is now 'flim flam'?
I mean, who do the CDC think they are pronouncing on public health?!