Wait... you thought the title "Internet of Things" actually defines the way it works?
Nope. Making an ubiquitous "sensor network" is a problem by itself, because those sense will be put on the internet eventually. Why would you believe your sensors will somehow stay off the internet, in defiance to the trend of the last decade to put an 802.x or 8011.x NIC on absolutely everything?
distinctly different from having a corporation hold the data
Just like how personal webpages are now self-hosted? Oh, that's right, the entire concept of having a personal webpage was appropriated by Facebook and other corporations with centralized hosting.
You're making a lot of assumptions.
And you seem to have a negligent attitude toward security, and a terribly naive view of corporate world.
Here's how your IoT can proceed without being socially irresponsible: accept liability for the problem your "sensor network" produces. You shouldn't have a problem doing this if you believe the risks are small. If, however, you think this would be too much liability, then we must conclude the IoT industry, like coal based power, is externalizing its costs.
That still creates an exfiltration risk. Pretending that risk doesn't exist is negligence. Don't pretend any device has perfect security; most embedded hardware runs ancient kernels that have know exploits.
aggregating sensor data is not a bad idea as long as the data is... anonymized
Yes, that's still a terrible idea. It is very difficult to "anonymize" personal data, as it can usual be re-correlated back to whomever generated the data. Even simple traffic analysis - without knowing the content of the network packets - can betray important information to the world.
Even combining a bunch of sensor data so that you can reconstruct someone's whole schedule is useless without knowing who that person is
I don't believe you are really this stupid. Of course you can connect it back to the person. Listen to when the packets were sent from their house and correlate that with the timestamps on the server. That's only one way to de-anonymize records; some creative thinking will reveal more.
"Anonymized data" is magic pixie dust that internet businesses use to disguise how they monetizing user data.
We're seeing the current wave of WiFi-enabled devices because the cheap SoC parts now include a WiFi NIC. At some point in the future (I believe prototype hardware already exists) a new SoC will include a baseband processor and software defined radio. When that happens, all of these devices will no longer need your permission and LAN access to steal data - they will simply use the cellular networks.
If you buy these WiFi devices - regardless of your plans to deny them your gateway address - you are supporting the development of the next generation of devices that will be much harder to block. Stop giving them money. Yes, this might mean you have to give up some luxuries in the short-term, but it['s only going to get worse if you don't fight this now.
Ultimately "sensor network" is it. Data aggregation of your life and monitoring of your things is the goal of IoT.
That's exactly why we call it an "insanely bad idea". When you aggregate that much data about people, the risks are huge while the benefits are small and in many cases, still theoretical. Unfortunately, humans are bad at evaluating risk, which may be why you react strongly to the claim that the IoT is and will be full of "shoddy security by incompetent idiots who want more analytics data and ad revenue, and don't give a crap about your security".
It is patently obvious the data that "sensor network" produces will be exfiltrated quickly and easily. We have seen a many cases in the last year where data was stolen from business and government agencies. Only a total fool would claim that they have perfect security and will be able protect all that personal data forever. Even worse, current products show how the data will be exfiltrated by the manufacturer, as a "feature". By centralizing data, they make a better target and a single point of failure that only needs to be attacked once. Of course, attacking a network of cheap mass-produced IoT devices shouldn't be hard - it's a monoculture that will all fall to the same type of attack.
This security problem should be obvious, and anybody involved in making these 1oT "sensor networks" is either wilfully negligent or has another agenda. A responsible person would notice that "ease of use" never overrides "safety".
Trends...
Yet again, you do not need internet access to make devices that logs trends in sensor data. The only reason that is so important is that you either don't understand the various hardware possibilities you could be using instead, or you are hiding that you are a thief trying to "monetize" the "analytics" produced by these devices.
Quite right. Even though I believe systemd is very poorly designed and is badly damaging the Linux ecosystem, there is also the concept of picking your battles. Badly off-topic rants are counterproductive.
"I don't know how systemd works..."
This kind of willfully-blind pro-systemd talking point is also inappropriate. This often-repeated claim is uninformed projection. If you want to join the argument, please actually listen to what the complaints about systemd actually are (it isn't an unwillingness to learn new tools)... in another thread!
China is showing us one of the possible end games. Facebook is already patenting features along those lines. Combined with omnipresent spying, this "new" type of oppression will work. It's a terrifying future.
It's like a new cold war.
Dan Geer describes our situation as a cold civil war. It would be useful if more people recognized that.
Yes. That's the sacrifice I talked about. There was a time many years ago when these problems could be fought without needing a sacrifice. Now, fighting against these trends requires a sacrifice. You might not get to watch TV. That might even impact other areas of your life. It might even be a significant loss of wage or opportunity. Why would you think fighting against a well-funded opponent would be free or easy?
My point was that these costs are increasing. You can pay this cost now, which requires some sacrifice, or you can signal your acceptance of these policies making any future attempt to fight back even harder. Do you want to sacrifice "merely" some luxuries like TV? Or do you want to wait until it requires sacrificing a lot more? Going without TV is easy. Try fighting this when the only refrigerator you can buy is "smart".
Hyperbole? Only if "call the authorities" is the only thing that spyware like this does. Given the news of the last few years, you should know that there are a lot more risks from spyware than a simple broken crash sensor.
As for your insistence on seeing an "example, real world" - why is it that apologists like you always freak out any time someone suggest that at problem needs to be fixed before it injures someone? Are you only willing to care about something after someone has their life ruined? Are you so suspicious of others that you won't believe them when they point out problems?
Beliefs like this - a just-world hypothesis - is one of the key problem of the modern world. Stop giving the benefit of the doubt when it it isn't deserved.
If I can make it secure, why should I waste money on a streaming device when the feature is built in to my TV?
If you buy a "spyware" TV, but disable any problematic feature, you are sending the message to the manufacturer that they can get away with more of this crap in the future. Only by hitting them where they notice - their profit - will they change their behavior.
The same goes for any other product. Technically capable people that disable malicious features but still buy the product are a big part of the problem. People look to the techies when they consider new technologies. When they see "spyware" TVs being used, they get the idea that it's safe to buy one for themselves, except they are not going to be able to disable the malicious features.
As long as you value TV more than your security, privacy, and future freedom, businesses will continue to make their product more malicious. Fighting back against power often requires sacrifice; I strongly suggest fighting this now while it only require sacrificing a new TV for a while. If you wait, this fight will only become harder.
That will only work for a little while. Once the next generation of system-on-a-chips are available, these spyware devices will simply connect to the cellular network at off-peak hours.
Each script is a bunch of boilerplate that has to reimplement the same stuff.
So shared libraries don't exist? That hasn't been a problem in a long time on BSD or OpenRC systems. Seriously, it's not hard to factor out code into a library. If you're only considering Debian, you have to remember that they are always behind (sometimes FAR behind) the update cycle.
The functionality is inconsistent between services.
Again, only if you were a moron and reinvented the wheel each script instead of using a common library.
That said, the ability to do things different is very important when you need to support something unusual.
To check whether a service is running, it uses pid files.
No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.
It doesn't have useful logging.
Again, this is by design, as it left logging *unspecified*. If you don't like syslog, nothing was preventing you from using something else. (also, "useful" is subjective)
because init doesn't log service crashes.
Patently incorrect, as I have used syslog to inspect startup crashes many times over the last *twenty years* I've been using UNIX. Maybe this has been a problem for other people, but I've never seen it. If your syslog is configured badly, that's an entirely separate problem.
Yay for "sleep" hacks.
While I can't speak for all distributions (you seem to have had some history with poorly-configured environments), there is nothing wrong with using sleep based polling. The only reliable way to detect if a prerequisite service is ready is by directly polling the service. (e..g issue an HTTP GET to a web server) The timeout is to allow startup to proceed in case of an error, (so you don't end up bricked, unable to use your computer)
on demand
There is a reason most distributions stopped using super-servers like xinetd: on-demand startup isn't that useful. Start your service at boot. You can defer expensive tasks until the first requests, if you want, which is when you would pay that cost anyway in an "on demand" launch. Listen to on the port, block on accept(2) or select(2) or similar, and let the OS page you out to the swap partition.
"On demand" isn't necessary, because the kernel already provides that feature. Adding a redundant implementation simply increases complexity and adds more opportunity for bugs. Super-servers make it even worse, as they add the risk that a problem in on service could take down all the services provided by the super-server.
Breaks horribly the moment something goes wrong.
Ok, now you're just trolling.
Want to have some fun? On a systemd box, pretend you just installed some updates, and you need to restart a few daemons so they run the updated versions. Try restarting dbus (system, not user). (You might want to make sure any open files are saved first)
Also, you might want to actually read about UNIX before you make these kinds of accusations. Reading taoup is a good place to start.
hey typically render pixmaps and just have the X server composite them
This is just nonsense. Your applications may be overly pixmap based (certain GTK+ engines started that mess when people prioritized "themes" over good design), but it is foolish to assume everybody else uses the same limited set of software. Remember, most of the software in the world is smaller private stuff used internally by businesses, academia, etc. Simply asserting that nobody uses various features doesn't make it true.
Wayland advocates really need to learn one of the most important lessons of software design, which was best explained by Joel Spolsky's essay "Things You Should Never Do, Part I".
[Y]ou can ask almost any programmer today about the code they are working on. "It's a big hairy mess," they will tell you. "I'd like nothing better than to throw it out and start over."
Why is it a mess?
"Well," they say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for." [...]
The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. [...]
Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. [...]
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
Yes, there are rough areas in X11 that really need to be fixed. That's true for almost any software project of sufficient size. Fortunately, the extension system in X11 allows a lot of those problems to be solved one at a time, while retaining backwards compatibility. The people that believe the very existence of backwards must somehow be a bottleneck are not creating the next version of X. Instead, they are creating something new. This is fine, but by their own definition, it is not a replacement for X11, and if Wayland tries to be such a replacement, it will inevitably grow to a similar level of "messiness" as numerous fixes, workarounds, and minor features are re-invented.
The problem with Wayland (and many other modern "replacement" projects, with systemd as the canonical example) is not technical in nature, but the hubris that so easily throws out so many man-years of effort.
Scare quotes around spy? Your contempt towards people who think they should own their computer, not Microsoft, in duly noted.
You claim that since it's possible to disable Microsoft's spyware ("telemetry"), people should use Windows 10 instead of 8.1 (or, presumably, any other earlier version of Windows. For the moment, i will assume that you indeed have the ability to find 0all of the ways Microsoft is harvesting data (including supposedly "anonymized" statistics), and have some sort of method (or free time) to police all the forced updates in the future that may try to re-enable those features. I will also assume that Windows 10 is, as you say, "100% better", even though this is a situational claim that depends a lot on subjective opinion.
So Microsoft releases a version of windows that is actively hostile to it's users. You could choose the capitalist response and resisted upgrading punish them in the market until released a product people wanted ot buy. You could have chosen to avoid the problem by using a different vendor (or no vendor. You could have simply decided that your data is more important than shiny baubles and stayed with an earlier version of windows. You could have even taken a different approach an appealed to Microsoft (as a politician, as a journalist or even simply as a customer) to release a version of Windows 10 (perhaps at a higher price) that didn't have the features you don't want and will have to spend time removing. All of these options signal correctly to Microsoft that maybe they shouldn't be so brazen and presumptuous with user data in the future.
Instead, you choose to pay Microsoft (either directly with cash or indirectly with your data and privacy. By choosing to reward Microsoft for their decision to make Windows into spyware., you are conditioning them to continue adding spyware to their products. By choosing to shield Microsoft form the costs of cleaning up their own mess by paying your own time to "disable all the telemetry", you bias the feedback they receive even further towards "more spyware".
Of course, I'm being a bit presumptuous. You didn't actually claim to have disabled telemetry yourself, so the better interpretation of your comment is that you are an apparatchik - a true believer that truly believes the "features" provided in Windows 10 are worth more than the your future privacy.
Eventually, Microsoft will release yet another version of windows (they've always love their service packs) that you finally offends even the sensibilities of the apparatchick. Maybe you finally woke up to the full breadth of what they are collection. Maybe you finally got tired trying to find all the new laces they hide their "telemetry" spyware every time new patches show up on Windows Update. You will be very annoyed, but remember, you asked for that future by staying with Windows. You asked to be spied on when you continued to pay them. Well, I hope you enjoy the consequences. of those choices.
So the shills have been copying Scientology's "what are your crimes" deflection tactic for a while now. I wonder who approved that plan, as it didn't work for CoS either.
Even if we assume this is accurate and this "telemetry" data is the only spying they are doing (a patently incorrect assumption), this is still an incredible amount of metadata being collected.
A lot of people - even some that should know better - have bought the propaganda that spying on "metadata" doesn't matter. In reality, metadata (or "anonymous" usage statistics) is the most valuable data that can be collected in bulk. As former CIA and NSA director Michael Hayden said, "We kill people based on metadata..
This data is obviously profitable among the businesses using surveillance as a business model because you are the product, but that's not the biggest problem.
Knowing what programs you run - and when you run them - can be enough to start building a pattern of life profile. When do you wake up. When do you spend time near your home router's IP address running a web browser. When do you tend to run MS Office, with the telemetry coming from an IP owned by business instead of your usual home IP? I'm sure modern data analysis tools could find a lot more interesting stuff out of telemetry data.
That's what you get when you buy a product that depends on a single vendor for its mission-critical supply chain.
As you are a marine, you should be concerned about how much of your ability to function as an armed force depends strictly on a single vendor. Engineering fields and especially defence suppliers traditionally required a second source for any mission-critical parts.
Every time I see people discussing AMT, they leave out the final piece of the puzzle: Intel's SGX ("Software Guard Extensions") instructions that are in Skylake and future CPUs. SGX lets a program set up "secure enclaves" in RAM that are encrypted in the CPU and cannot be accessed by other programs, including the OS itself. As the data is encrypted outside of the CPU, you cannot even use a cold-boot attack or a logic analyser to access the data the hard way.
The only people talking about these instructions seem to be the occasional crypto researcher musing about how this could be a nice feature for protecting private keys. I'm sure that's possible, but Intel clearly has another goal in mind.
1. Allow application developers to protect sensitive data from unauthorized access or modification by rogue software running at higher privilege levels.
[...]
5. Enable the development of trusted applications [...]
6. Enable software vendors to deliver trusted applications and updates [...]
[...]
8. Enable applications to define secure regions of code and data that maintain confidentiality even when an attacker has physical control of the platform and can conduct direct attacks on memory.
In case anybody has forgotten, "trusted applications" is a dog whistle for DRM, originally popularized by Microsoft when they announced "Palladium". Good luck investigating what AMT is doing when the RAM it uses is encrypted.
Of course, some people in this very thread are already apologizing for Intel and claiming AMT isn't a threat. They probably said the same thing about Windows 10, too, with claims that the spyware wasn't important because it could (with much hassle) be disabled. Well, good luck in future Windows versions when the spyware is an encrypted SGX enclave.
The problem is Intel's new SGX ("Software Guard Extensions"). They allow the creation of memory regions that "maintain confidentiality even when an attacker has physical control of the platform and can conduct direct attacks on memory". The CPU encrypts RAM so you cannot pull keys out of it with a cold boot attack or a logic analyser on the memory bus.
Of course, the rare news article about SGX likes to assume this is something intended for the user so they can protect their GPG keys. What nobody is talking about is that this lets, for example, Microsoft create unbreakable DRM. MS will finally have their infamous Palladium "trusted computing" platform. They have already started the chain-of-trust with UEFI's SecureBoot. I hope people are taking the hint now with the Windows 10 scandal and fleeing the platform, because you aren't going to be able to remove their spyware once it is in the "trusted" enclave.
If that isn't worrying enough, consider what hidden SGX enclaves means for Intel's System Management Mode - the network enabled BIOS feature that allows remote access - which is already in your computer if have an Intel system newer than ~2010. This even works independent of the installed OS, so you can't get away from SMM by using Linux.
Ever get the feeling you don't actually own your computer? Current "trusted computing" design allows an untrusted OS to run most of the time by implementing the DRM/spyware at a lower hardware protection ring while making sure plaintext never leaves the CPU.
You're deliberately conflating ownership of a creative work's copyright with ownership of an individual copy of that work (which was made by the party who did own the copyright). The only right the granted by copyright is the right to a monopoly on who can create new instances (copies) of a given work, and that right absolutely does not extend beyond that.
This is called the first-sale doctrine, which recognizes that reproduction rights are distinct form distribution rights, with copyright only granting the former and their distribution rights end at the first sale. If a retailer buys a copyright-protected work at wholesale, they can sell it however they like as long as they do not create any more copies. Likewise, if you buy such a work, you can use it for whatever you like, provided you don't make additional copies. If the party that owns the copyright wants more control over what happens after the first sale, they can always negotiate a contract with additional restrictions. This happens often when publishers sell wholesale to retailers. Just remember that an EULA is not a contract, and anybody that buys something in a simple retail transaction ("I pay you money, you hand me $GAME" only) has not agreed to any extra restrictions.
A lot of publishers really wish they could control their product after the first sale so they can eliminate the resale market. They can dream all they want, but that doesn't change the law.
Note: it's a mistake to assume someone is looking for the forecast for their current location or the GPS location given by their network device (which may not be the same as their current location). If your service only worked by GPS, it would be giving the wrong forecast in some cases.
How about asking the user, and respecting their choice? Ask them if they want to give their GPS location for a specific forecast, or if they would prefer to type in a zip an get a generalized forecast. There could be reasons people might want either of those options, and they might like it if your service supported both. It's not like it would be hard (just lookup a default location for each zip and use that instead of the GPS; it only requires one table in the DB). You probably already do this for backwards compatibility with non-GPS-enabled devices.
The *only* reason not to offer that is if you aren't really interested in providing weather forecasts, but instead are trying to jump o the surveillance-as-a-business-model bandwagon. If that's the case, you should think long and hard about your new job - do you really want to be associated with peeping toms?
And then came the assumptions. And the assumptions were without form.
And the plan was without substance. And darkness was upon the face of the workers.
And they spoke among themselves saying, "It is a crock of shit and it stinketh."
And the workers went unto their supervisors and said, "It is a pale of dung and none may abide the odor thereof."
And the supervisor went unto their managers and said, "It is a container of excrement and it is very strong, such that none may abide by it."
And the managers went unto their directors, saying, "It is a vessel of fertilizer, and none may abide its strength."
And the directors spoke among themselves, saying to one another, "It contains that which aids plant growth and it is very strong."
And the directors went unto the vice presidents, saying unto them, "It promotes growth and is very powerful."
And the vice presidents went unto the president, saying unto him, "The new plan will promote the growth and vigor of the company, with powerful effects."
And the president looked upon the plan and saw that it was good. And the plan became policy.
Why is it that so many people seem to think that it's no big deal to open a connection to a random host on the internet? That puts you in yet another situation where you have to enumerate badness.
In this case, what you just described allows someone to probabilistically verify that someone saw a page (regardless of how they got the HTML - email/spam, HTTP, or a README.html found in a warez.zip). Marking links as prefetchable is something the malicious party can do on their own, so it offers zero protection, and a single packet all that is needed to track you.. Of course, we're not talking about a single packet, as this stupid "feature" does the entire transport layer including the SSL connection, not just the TCP 3-way-handshake.
I suggest thinking long and hard about what any of this data can be correlated with (temporally or as a matching surrogate key), remember that it doesn't have to work all the time. Single data points are usually safe on their own, but the pattern that emerges when you join someone's data trail together can be very detailed.
We need a reduction of data that browsers transmit, in this post-Snowden world.
Slashdot Mirror
Nope. Making an ubiquitous "sensor network" is a problem by itself, because those sense will be put on the internet eventually. Why would you believe your sensors will somehow stay off the internet, in defiance to the trend of the last decade to put an 802.x or 8011.x NIC on absolutely everything?
Just like how personal webpages are now self-hosted? Oh, that's right, the entire concept of having a personal webpage was appropriated by Facebook and other corporations with centralized hosting.
And you seem to have a negligent attitude toward security, and a terribly naive view of corporate world.
Here's how your IoT can proceed without being socially irresponsible: accept liability for the problem your "sensor network" produces. You shouldn't have a problem doing this if you believe the risks are small. If, however, you think this would be too much liability, then we must conclude the IoT industry, like coal based power, is externalizing its costs.
That still creates an exfiltration risk. Pretending that risk doesn't exist is negligence. Don't pretend any device has perfect security; most embedded hardware runs ancient kernels that have know exploits.
Yes, that's still a terrible idea. It is very difficult to "anonymize" personal data, as it can usual be re-correlated back to whomever generated the data. Even simple traffic analysis - without knowing the content of the network packets - can betray important information to the world.
I don't believe you are really this stupid. Of course you can connect it back to the person. Listen to when the packets were sent from their house and correlate that with the timestamps on the server. That's only one way to de-anonymize records; some creative thinking will reveal more.
"Anonymized data" is magic pixie dust that internet businesses use to disguise how they monetizing user data.
On Taxis and Rainbows
“Anonymized” data really isn’t
We're seeing the current wave of WiFi-enabled devices because the cheap SoC parts now include a WiFi NIC. At some point in the future (I believe prototype hardware already exists) a new SoC will include a baseband processor and software defined radio. When that happens, all of these devices will no longer need your permission and LAN access to steal data - they will simply use the cellular networks.
If you buy these WiFi devices - regardless of your plans to deny them your gateway address - you are supporting the development of the next generation of devices that will be much harder to block. Stop giving them money. Yes, this might mean you have to give up some luxuries in the short-term, but it['s only going to get worse if you don't fight this now.
That's exactly why we call it an "insanely bad idea". When you aggregate that much data about people, the risks are huge while the benefits are small and in many cases, still theoretical. Unfortunately, humans are bad at evaluating risk, which may be why you react strongly to the claim that the IoT is and will be full of "shoddy security by incompetent idiots who want more analytics data and ad revenue, and don't give a crap about your security".
It is patently obvious the data that "sensor network" produces will be exfiltrated quickly and easily. We have seen a many cases in the last year where data was stolen from business and government agencies. Only a total fool would claim that they have perfect security and will be able protect all that personal data forever. Even worse, current products show how the data will be exfiltrated by the manufacturer, as a "feature". By centralizing data, they make a better target and a single point of failure that only needs to be attacked once. Of course, attacking a network of cheap mass-produced IoT devices shouldn't be hard - it's a monoculture that will all fall to the same type of attack.
This security problem should be obvious, and anybody involved in making these 1oT "sensor networks" is either wilfully negligent or has another agenda. A responsible person would notice that "ease of use" never overrides "safety".
Yet again, you do not need internet access to make devices that logs trends in sensor data. The only reason that is so important is that you either don't understand the various hardware possibilities you could be using instead, or you are hiding that you are a thief trying to "monetize" the "analytics" produced by these devices.
Quite right. Even though I believe systemd is very poorly designed and is badly damaging the Linux ecosystem, there is also the concept of picking your battles. Badly off-topic rants are counterproductive.
This kind of willfully-blind pro-systemd talking point is also inappropriate. This often-repeated claim is uninformed projection. If you want to join the argument, please actually listen to what the complaints about systemd actually are (it isn't an unwillingness to learn new tools)... in another thread!
China is showing us one of the possible end games. Facebook is already patenting features along those lines. Combined with omnipresent spying, this "new" type of oppression will work. It's a terrifying future.
Dan Geer describes our situation as a cold civil war. It would be useful if more people recognized that.
Yes. That's the sacrifice I talked about. There was a time many years ago when these problems could be fought without needing a sacrifice. Now, fighting against these trends requires a sacrifice. You might not get to watch TV. That might even impact other areas of your life. It might even be a significant loss of wage or opportunity. Why would you think fighting against a well-funded opponent would be free or easy?
My point was that these costs are increasing. You can pay this cost now, which requires some sacrifice, or you can signal your acceptance of these policies making any future attempt to fight back even harder. Do you want to sacrifice "merely" some luxuries like TV? Or do you want to wait until it requires sacrificing a lot more? Going without TV is easy. Try fighting this when the only refrigerator you can buy is "smart".
Hyperbole? Only if "call the authorities" is the only thing that spyware like this does. Given the news of the last few years, you should know that there are a lot more risks from spyware than a simple broken crash sensor.
As for your insistence on seeing an "example, real world" - why is it that apologists like you always freak out any time someone suggest that at problem needs to be fixed before it injures someone? Are you only willing to care about something after someone has their life ruined? Are you so suspicious of others that you won't believe them when they point out problems?
Beliefs like this - a just-world hypothesis - is one of the key problem of the modern world. Stop giving the benefit of the doubt when it it isn't deserved.
If you buy a "spyware" TV, but disable any problematic feature, you are sending the message to the manufacturer that they can get away with more of this crap in the future. Only by hitting them where they notice - their profit - will they change their behavior.
The same goes for any other product. Technically capable people that disable malicious features but still buy the product are a big part of the problem. People look to the techies when they consider new technologies. When they see "spyware" TVs being used, they get the idea that it's safe to buy one for themselves, except they are not going to be able to disable the malicious features.
As long as you value TV more than your security, privacy, and future freedom, businesses will continue to make their product more malicious. Fighting back against power often requires sacrifice; I strongly suggest fighting this now while it only require sacrificing a new TV for a while. If you wait, this fight will only become harder.
That will only work for a little while. Once the next generation of system-on-a-chips are available, these spyware devices will simply connect to the cellular network at off-peak hours.
Precedent? "Onstar"
So shared libraries don't exist? That hasn't been a problem in a long time on BSD or OpenRC systems. Seriously, it's not hard to factor out code into a library. If you're only considering Debian, you have to remember that they are always behind (sometimes FAR behind) the update cycle.
Again, only if you were a moron and reinvented the wheel each script instead of using a common library.
That said, the ability to do things different is very important when you need to support something unusual.
No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.
Again, this is by design, as it left logging *unspecified*. If you don't like syslog, nothing was preventing you from using something else. (also, "useful" is subjective)
Patently incorrect, as I have used syslog to inspect startup crashes many times over the last *twenty years* I've been using UNIX. Maybe this has been a problem for other people, but I've never seen it. If your syslog is configured badly, that's an entirely separate problem.
While I can't speak for all distributions (you seem to have had some history with poorly-configured environments), there is nothing wrong with using sleep based polling. The only reliable way to detect if a prerequisite service is ready is by directly polling the service. (e..g issue an HTTP GET to a web server) The timeout is to allow startup to proceed in case of an error, (so you don't end up bricked, unable to use your computer)
There is a reason most distributions stopped using super-servers like xinetd: on-demand startup isn't that useful. Start your service at boot. You can defer expensive tasks until the first requests, if you want, which is when you would pay that cost anyway in an "on demand" launch. Listen to on the port, block on accept(2) or select(2) or similar, and let the OS page you out to the swap partition.
"On demand" isn't necessary, because the kernel already provides that feature. Adding a redundant implementation simply increases complexity and adds more opportunity for bugs. Super-servers make it even worse, as they add the risk that a problem in on service could take down all the services provided by the super-server.
Ok, now you're just trolling.
Want to have some fun? On a systemd box, pretend you just installed some updates, and you need to restart a few daemons so they run the updated versions. Try restarting dbus (system, not user). (You might want to make sure any open files are saved first)
Also, you might want to actually read about UNIX before you make these kinds of accusations. Reading taoup is a good place to start.
This is just nonsense. Your applications may be overly pixmap based (certain GTK+ engines started that mess when people prioritized "themes" over good design), but it is foolish to assume everybody else uses the same limited set of software. Remember, most of the software in the world is smaller private stuff used internally by businesses, academia, etc. Simply asserting that nobody uses various features doesn't make it true.
Wayland advocates really need to learn one of the most important lessons of software design, which was best explained by Joel Spolsky's essay "Things You Should Never Do, Part I".
Yes, there are rough areas in X11 that really need to be fixed. That's true for almost any software project of sufficient size. Fortunately, the extension system in X11 allows a lot of those problems to be solved one at a time, while retaining backwards compatibility. The people that believe the very existence of backwards must somehow be a bottleneck are not creating the next version of X. Instead, they are creating something new. This is fine, but by their own definition, it is not a replacement for X11, and if Wayland tries to be such a replacement, it will inevitably grow to a similar level of "messiness" as numerous fixes, workarounds, and minor features are re-invented.
The problem with Wayland (and many other modern "replacement" projects, with systemd as the canonical example) is not technical in nature, but the hubris that so easily throws out so many man-years of effort.
Scare quotes around spy? Your contempt towards people who think they should own their computer, not Microsoft, in duly noted.
You claim that since it's possible to disable Microsoft's spyware ("telemetry"), people should use Windows 10 instead of 8.1 (or, presumably, any other earlier version of Windows. For the moment, i will assume that you indeed have the ability to find 0all of the ways Microsoft is harvesting data (including supposedly "anonymized" statistics), and have some sort of method (or free time) to police all the forced updates in the future that may try to re-enable those features. I will also assume that Windows 10 is, as you say, "100% better", even though this is a situational claim that depends a lot on subjective opinion.
So Microsoft releases a version of windows that is actively hostile to it's users. You could choose the capitalist response and resisted upgrading punish them in the market until released a product people wanted ot buy. You could have chosen to avoid the problem by using a different vendor (or no vendor. You could have simply decided that your data is more important than shiny baubles and stayed with an earlier version of windows. You could have even taken a different approach an appealed to Microsoft (as a politician, as a journalist or even simply as a customer) to release a version of Windows 10 (perhaps at a higher price) that didn't have the features you don't want and will have to spend time removing. All of these options signal correctly to Microsoft that maybe they shouldn't be so brazen and presumptuous with user data in the future.
Instead, you choose to pay Microsoft (either directly with cash or indirectly with your data and privacy. By choosing to reward Microsoft for their decision to make Windows into spyware., you are conditioning them to continue adding spyware to their products. By choosing to shield Microsoft form the costs of cleaning up their own mess by paying your own time to "disable all the telemetry", you bias the feedback they receive even further towards "more spyware".
Of course, I'm being a bit presumptuous. You didn't actually claim to have disabled telemetry yourself, so the better interpretation of your comment is that you are an apparatchik - a true believer that truly believes the "features" provided in Windows 10 are worth more than the your future privacy.
Eventually, Microsoft will release yet another version of windows (they've always love their service packs) that you finally offends even the sensibilities of the apparatchick. Maybe you finally woke up to the full breadth of what they are collection. Maybe you finally got tired trying to find all the new laces they hide their "telemetry" spyware every time new patches show up on Windows Update. You will be very annoyed, but remember, you asked for that future by staying with Windows. You asked to be spied on when you continued to pay them. Well, I hope you enjoy the consequences. of those choices.
This seems like it was specifically designed to to generate libel lawsuits.
So the shills have been copying Scientology's "what are your crimes" deflection tactic for a while now. I wonder who approved that plan, as it didn't work for CoS either.
Even if we assume this is accurate and this "telemetry" data is the only spying they are doing (a patently incorrect assumption), this is still an incredible amount of metadata being collected.
A lot of people - even some that should know better - have bought the propaganda that spying on "metadata" doesn't matter. In reality, metadata (or "anonymous" usage statistics) is the most valuable data that can be collected in bulk. As former CIA and NSA director Michael Hayden said, "We kill people based on metadata..
This data is obviously profitable among the businesses using surveillance as a business model because you are the product, but that's not the biggest problem.
Knowing what programs you run - and when you run them - can be enough to start building a pattern of life profile. When do you wake up. When do you spend time near your home router's IP address running a web browser. When do you tend to run MS Office, with the telemetry coming from an IP owned by business instead of your usual home IP? I'm sure modern data analysis tools could find a lot more interesting stuff out of telemetry data.
That's what you get when you buy a product that depends on a single vendor for its mission-critical supply chain.
As you are a marine, you should be concerned about how much of your ability to function as an armed force depends strictly on a single vendor. Engineering fields and especially defence suppliers traditionally required a second source for any mission-critical parts.
Then again, what do I know. Given that the armed forces seem to be fine depending on China for most military hardware, what's another Sword of Damocles hanging our head?
if the owner of the PC chooses
No, the OEM will get to choose, just like they do today in other areas. I suppose the laptops with UEFI SecureBoot enabled don't exist in your world?
I work for Intel
So you're a collaborator. I hope you like the future you're creating. Maybe you should wake up to what is actually happening in the world?
Every time I see people discussing AMT, they leave out the final piece of the puzzle: Intel's SGX ("Software Guard Extensions") instructions that are in Skylake and future CPUs. SGX lets a program set up "secure enclaves" in RAM that are encrypted in the CPU and cannot be accessed by other programs, including the OS itself. As the data is encrypted outside of the CPU, you cannot even use a cold-boot attack or a logic analyser to access the data the hard way.
The only people talking about these instructions seem to be the occasional crypto researcher musing about how this could be a nice feature for protecting private keys. I'm sure that's possible, but Intel clearly has another goal in mind.
In case anybody has forgotten, "trusted applications" is a dog whistle for DRM, originally popularized by Microsoft when they announced "Palladium". Good luck investigating what AMT is doing when the RAM it uses is encrypted.
Of course, some people in this very thread are already apologizing for Intel and claiming AMT isn't a threat. They probably said the same thing about Windows 10, too, with claims that the spyware wasn't important because it could (with much hassle) be disabled. Well, good luck in future Windows versions when the spyware is an encrypted SGX enclave.
The problem is Intel's new SGX ("Software Guard Extensions"). They allow the creation of memory regions that "maintain confidentiality even when an attacker has physical control of the platform and can conduct direct attacks on memory". The CPU encrypts RAM so you cannot pull keys out of it with a cold boot attack or a logic analyser on the memory bus.
Of course, the rare news article about SGX likes to assume this is something intended for the user so they can protect their GPG keys. What nobody is talking about is that this lets, for example, Microsoft create unbreakable DRM. MS will finally have their infamous Palladium "trusted computing" platform. They have already started the chain-of-trust with UEFI's SecureBoot. I hope people are taking the hint now with the Windows 10 scandal and fleeing the platform, because you aren't going to be able to remove their spyware once it is in the "trusted" enclave.
If that isn't worrying enough, consider what hidden SGX enclaves means for Intel's System Management Mode - the network enabled BIOS feature that allows remote access - which is already in your computer if have an Intel system newer than ~2010. This even works independent of the installed OS, so you can't get away from SMM by using Linux.
Ever get the feeling you don't actually own your computer? Current "trusted computing" design allows an untrusted OS to run most of the time by implementing the DRM/spyware at a lower hardware protection ring while making sure plaintext never leaves the CPU.
You're deliberately conflating ownership of a creative work's copyright with ownership of an individual copy of that work (which was made by the party who did own the copyright). The only right the granted by copyright is the right to a monopoly on who can create new instances (copies) of a given work, and that right absolutely does not extend beyond that.
This is called the first-sale doctrine, which recognizes that reproduction rights are distinct form distribution rights, with copyright only granting the former and their distribution rights end at the first sale. If a retailer buys a copyright-protected work at wholesale, they can sell it however they like as long as they do not create any more copies. Likewise, if you buy such a work, you can use it for whatever you like, provided you don't make additional copies. If the party that owns the copyright wants more control over what happens after the first sale, they can always negotiate a contract with additional restrictions. This happens often when publishers sell wholesale to retailers. Just remember that an EULA is not a contract, and anybody that buys something in a simple retail transaction ("I pay you money, you hand me $GAME" only) has not agreed to any extra restrictions.
A lot of publishers really wish they could control their product after the first sale so they can eliminate the resale market. They can dream all they want, but that doesn't change the law.
Note: it's a mistake to assume someone is looking for the forecast for their current location or the GPS location given by their network device (which may not be the same as their current location). If your service only worked by GPS, it would be giving the wrong forecast in some cases.
How about asking the user, and respecting their choice? Ask them if they want to give their GPS location for a specific forecast, or if they would prefer to type in a zip an get a generalized forecast. There could be reasons people might want either of those options, and they might like it if your service supported both. It's not like it would be hard (just lookup a default location for each zip and use that instead of the GPS; it only requires one table in the DB). You probably already do this for backwards compatibility with non-GPS-enabled devices.
The *only* reason not to offer that is if you aren't really interested in providing weather forecasts, but instead are trying to jump o the surveillance-as-a-business-model bandwagon. If that's the case, you should think long and hard about your new job - do you really want to be associated with peeping toms?
How a plan becomes policy
constables
There are many different types of threats on the net that, and a few are law enforcement.
Why is it that so many people seem to think that it's no big deal to open a connection to a random host on the internet? That puts you in yet another situation where you have to enumerate badness.
In this case, what you just described allows someone to probabilistically verify that someone saw a page (regardless of how they got the HTML - email/spam, HTTP, or a README.html found in a warez .zip). Marking links as prefetchable is something the malicious party can do on their own, so it offers zero protection, and a single packet all that is needed to track you.. Of course, we're not talking about a single packet, as this stupid "feature" does the entire transport layer including the SSL connection, not just the TCP 3-way-handshake.
I suggest thinking long and hard about what any of this data can be correlated with (temporally or as a matching surrogate key), remember that it doesn't have to work all the time. Single data points are usually safe on their own, but the pattern that emerges when you join someone's data trail together can be very detailed.
We need a reduction of data that browsers transmit, in this post-Snowden world.