I understand your point completely. It's reality vs. the invisible pink unicorn ideal of perfect segregation of data, apps, and OS. But if end users aren't going to expect and demand improvements, very few packages will actually be improved on their own. It's good for all of us that people keep trying, even though there's not a snowball's chance in hell that he will recover it without a hitch.
Discovering "the smartest thing he could do" when referring to that laughable bumblefuck is pretty much identifying the short list of things he will never do. The man is stupider than he is ugly, and that's no mean feat.
For problems like this, if the stakeholder insists on proceeding down the ill-advised path, I will try to add a configuration option to mitigate the dangerous behavior. When they come back saying "oh, no, we wish it didn't do this", (and they occasionally do) a switch-flip and they're back in business.
Its amazing to watch the confusion among scientists as the entire structure of the machine goes into a state of superposition with being real and not real all at the same time.
All quantum computers are real, unless declared integer.
And yet, what would the programmer do in this case? Code to spec, code as he thinks it should work, or go back to get better specs?
In a fixed price project you bet I'd do the first! I don't have time to do the correct thing (get better specs) and I'm not failing any tests on my own dime.
This is sadly true, and I've seen it a lot. When a developer is motivated by a deadline, other people's screw ups are just things that interfere with meeting that date. Any fixes will come out of the padding in the estimates, and once that padding is gone, so is the programmer's motivation to fix them. Those kinds of bugs then get quietly swept under the rug, or if they do get brought up in advance, people start arguing about who made them, who should fix them, who will test them, and in which future release will they go out to the customer.
In this particular example, the bug is egregious, and I'd expect the programmer to make the 5 minute effort to clarify the spec. The difference is that most programmers understand math well enough to catch a math error, but not every spec error is in their field of expertise. What if the mistake was in the calculation of tax, and the programmer doesn't understand the tax laws well enough to spot the error? That bug is going to sail right through every test, and the developers will deliver their perfect-to-spec-yet-still-buggy code.
The specs are never as good as the spec writers think they are.
I've been a developer (contractor and employee) for nearly 20 years and have never seen specs that clearly defined everything.
Given the spec is incomplete, and your experience, wouldn't best practice be to analyse the requirements at the start and identify those edge cases and get decisions on them before starting.
The fact is that no set of specs are ever perfect, and the dangerous fallacy is in believing that they can be made perfect. And even if you can hone and polish them to a glistening perfection today, the problem domain the design is addressing will often change between the time the specs are written and the time the software is delivered.
Specs have several kinds of errors: errors of omission, conflicting requirements, and incorrect requirements. Design activities can identify conflicts, but often can't find the others.
Way back in the early '80s when I got my degree the thing that was placed into our heads was to spend 90% of the time designing, 5% coding, and 5% testing. These days we seem to dive into coding way too early.
The figures of "90% design, 5% code" is very much tied to physical world engineering, and is valid advice when you're creating an unchangeable physical thing like a car or a bottle-forming machine. But think about how much computers have evolved in the last 30 years - it shouldn't surprise you to learn that software development methodologies have evolved as well. Unlike hardware, software is infinitely flexible, and changes can be made cheaply and continuously throughout the life of a product. So instead of spending 90% of project time on Big Design Up Front, iterative or Agile project management methodologies and flexible design methodologies such as Test Driven Development leverage the facts that the world is constantly changing, software is infinitely flexible, its design is malleable, and having fully automated tests enables rapid changes and continuous deployment. By writing a test first, you ensure that requirement (as received) is being met. Understanding that coding is a design activity (and not a construction activity - construction happens when you click "build") is key. By applying good design principles, code can be refactored from a functioning solution to an elegant design, and this activity takes place iteratively during coding.
They've been using 3D printed objects as patterns for investment casting of metal for over 20 years, since the advent of 3D printing. The problem is cast metals are often not the best solution for the end use of the part. For example, no cast metal is yet suitable for making molds or dies for high volume plastic injection molding, where it has to be extremely hard and shock resistant - P-type tool steel is the right material for molds, but I don't believe it can yet be precisely formed by casting.
However, an investment cast metal mold makes a great temporary mold or die if your production mold breaks. A company can print up and cast a mold and get their factory back on line within just a few days. The temporary mold may only last for a thousand parts, but that will often be enough to keep them on-line for the two months it takes to have a production mold made. If not, they print another and keep going.
Office365 was created for exactly one reason. It was created to convert customers from a pay-once model to a pay-as-you-go subscription model.
Who do you think Office2013's biggest competitor is? Open Office? Hardly. They're competing against the installed base of Office2010 users. They are competing against themselves. Long ago they ran out of truly useful features to add - how many users were clamoring for the ribbon bar, or Clippy? Once they improved their software engineering skills and drove out most of the bugs and security flaws, they removed all compelling reasons to upgrade. And that is cutting into their revenue stream. Subscription based software rental will keep the money taps open, but only if they can connive people into "upgrading" to it.
This change improves one thing only: Microsoft's cash flow. It was not changed out of a desire to improve upon a working product.
And what, in your expert opinion, is the right tool for the job? Back in the day I never bothered moving to pine, because I figured elm was good enough for me. (And it was.) Now I seem to spend half my workday in Outlook, and it makes me exactly every bit as productive as elm did. It's worse, actually, because these days everyone has email and it's now far too easy for the unwashed masses to cc: a status report to a hundred people who simply don't care.
If a newer tool doesn't provide a demonstrable or measurable improvement, what makes that new tool "right"? What makes the old tool "wrong"?
I'd also make the patent troll produce something from that patent - shit or get off the pot. If you are not using the patent, then you have no right in retaining it or using it against someone.
Actually, this is one point I'd disagree with.
If the inventor of the patent chooses to make their own widgets, are they really making their own, or are they contracting with a Chinese factory to produce them under license? Do you require the inventor to stand on the factory line and hand-assemble each and every patented widget personally? That quickly gets silly.
So the inventor can choose to make widgets themselves, they can license the ability to make widgets to other people, or they can cash out and sell the rights to license widget-making to someone else. Just like the inventor, that someone else doesn't have to make their own widgets - instead of selling widgets they can sell licenses to make widgets.
If the inventor chose the cash-out option, that's it. They struck a deal and were paid for their invention. The law ends there. They may have struck a bad deal, they may have been swindled by a fast talker on www.help-U-sell-your-patent.com, but that's just capitalism preying on the careless, and is no different from the sale of any other goods or services.
Force is a euphemism for blackmail, and it's not inaccurate when applied here. "Nice web site you got here, it'd be a shame if we had a court order you to take it down. Give us $100,000 and nothing bad will happen to it, or you risk losing a $100,000,000 in court if we win." That's force to a company that doesn't have $100,000,000 in their bank account.
Newegg's made a corporate decision that said "we don't care if it's a thousand times cheaper to settle than to risk losing a lawsuit. We have a very large pile of money, and we have promised to call every single bluff presented to us. We will never fold our hand."
That's what I read as well. It was so over-broad that it would have covered IBM 3270 terminals, which were a mainstay of the 1970s. They probably never tried suing IBM over it.
Here's the counter argument. Let's say you accidentally discover a vulnerability in a bank's web site by mistyping a URL and you ended up at a different customer's account. You write up your finding, and you privately send it to the bank's security team and ask them for nothing in return other than that they act quickly to protect your account. And let's say they turn around and accuse you of hacking them under the Computer Fraud and Abuse Act, and they provide your own written report to the Secret Service as evidence against you? Who is the ethical party?
How would money alter the ethics? If you gave them the details of the flaw and asked the bank for a $1,000 reward, would that change things? What if you offered to tell the bank of the flaw in exchange for $1,000? If they don't pay, are you ethically bound to not sell the vulnerability to a third party?
What if you don't know of any specific flaw in your bank's site, but you would like to make some side money as a pen tester; so you send them a letter asking if they have a "pay for vulnerability policy", and they respond by placing a hold on your account and calling in the Secret Service? Who is acting ethically in that scenario?
What if you fear retribution so you ask this question anonymously? Are you more or less suspicious to the bank? Should they be more or less likely to seek your prosecution?
What if you exploit the vulnerability personally to view Paris Hilton's bank balance, but you don't do anything malicious to her account? What if you disclose that balance information to the tabloids? What about viewing the bank data of a non-celebrity?
And if not the bank, which third party might you sell it to? A security researcher? A competing bank? Microsoft? A hacker? Some random alias on darkode?
Different people are likely to view these behaviors differently, including banks, law enforcement, hackers, computer security professionals, lawmakers, bank customers, and the general public. Different legal cases with different judges are likely to interpret these differently, as well.
There are few clear cut lines standing out among these questions that say "here are the exact boundaries of ethical behavior."
The article quotes the professor's example of a guy who revealed a flaw to a company that they were exposing hundreds of thousands of people's financial accounts. All he did was to change the user ID in his URL to some other number, which was a different person's account. He knew that his own information was at risk, and wanted the company to fix their badly written web site.
The reward for his reporting effort was a police investigation, and the company threatened him with the liability of the costs of fixing the flaw.
Sure, many companies will take a security report and say "oh, crap!" They'll then scurry about and fix the problem. They might say thank you, they might not. But the truth is some companies are run by total douche-nozzles who respond with threats.
When it's a possibility that companies will respond by acting as completely irrational and irresponsible as this, the professor is doing the right thing by teaching the students "don't assume any good will necessarily come from what you've done." If you monetize the flaw by selling it, someone else assumes the risk. They might buy it to exploit it, or they might hope to turn it into a reward.
His advice is to avoid the conflict entirely. It's amoral, but it's very practical advice that will keep you personally out of jail.
"This field contains an unexploded toy firecracker."
"This field contains no mines, but many shards of jagged, rusty, pointed steel."
"This field contains anthrax spores."
Now, if I had some reason to want to scare you away from this field, I might label it "this field contains less than fifty mines per hectare." It's perfectly true, but disingenuous.
You already have every piece of information you need to make an informed decision today.
The facts are a matter of public record. Look up the FCC ID on the label on your cell phone here: http://transition.fcc.gov/oet/ea/fccid/ Now, read the documentation that was filed in order to certify that device, and find out which sets of FCC rules it falls under to see the limits it must meet. You can also see the test reports they filed proving their device complied with all applicable rules.
If that information is inadequate to make an informed decision, how does giving you one single number suddenly make you competent to evaluate the health effects of a cell phone?
Here are the real facts that should be printed on a poster at every cell phone store in San Francisco: "WARNING: The city of Oakland is home to a crackpot who has built a lucrative speaking business convincing gullible, easily scared, and/or ignorant people about the imagined risks of cellular telephone RF emissions. If you do not own a cell phone strictly because of the irrational fears she is spreading you risk being stranded in case of emergency, which has been statistically proven to be far more dangerous to your health than any anecdotal based, non-scientific study."
You quoted misleading figures that have been out of date for over five years. Analog phones had a max power output of 3 watts, but hand-held transmitters that had their antenna next to the head were always limited to one watt max. Bag phones, which were car phones in a sack, transmitted up to three watts, but the antenna was in the bag. When Motorola came out with their dual mode phone (it slid into a car-mounted bracket for power, audio, and antenna connections), it switched itself to one watt max when in handset mode.
All digital cell phone handset technologies (CDMA, GSM) transmit 1 watt or less.
Honestly, that's what most annoys me about these sorts of cases(this, GMO labelling, 'organic' labeling, etc.) The evidence for harm or harmlessness is often rather equivocal; but the relevant trade association pressure groups scream like babies at the idea that customers would even be in the position to make an informed decision(foolish or otherwise).
Because it's ludicrous. Consider the same idea applied to a packaged cookie: "our whole wheat cookies contain less than 0.0001% arsenic, less than 1 picogram of lead, fewer than 15 anthrax spores per cookie, no more than 150 million viable microbes, below 72,000,000 mold spores," etc. The world is filled with trace amounts of stuff that humanity has ingested since the dawn of our species. It's only recently that we've even been able to recognize and measure it. And those are scientifically proven harmful ingredients at higher levels. We have standards that limit them.
The only people these numbers serve or placate are homeopaths, a completely self-deluded group of liars, charlatans, and idiots who do not deserve the respect you would afford a dead possum lying on the side of a road.
Here's the deal: if you want to know how much potentially harmful X is in a product, read the label. The information is already there, you just have to do your own research. Concerned about RF? There's an FCC ID printed on the case of your phone. Look up their filing. Read the relevant parts of the requirements they comply with pertaining to maximum allowable transmitted power. Read health studies of double blind experiments. It's all public information. But there is no way you should be spreading your irrational fears on someone else's product labels.
It's science, bitches. You want to believe in made up shit? Go to a fracking church, and close the doors behind you.
Slashdot Mirror
I understand your point completely. It's reality vs. the invisible pink unicorn ideal of perfect segregation of data, apps, and OS. But if end users aren't going to expect and demand improvements, very few packages will actually be improved on their own. It's good for all of us that people keep trying, even though there's not a snowball's chance in hell that he will recover it without a hitch.
Smartest thing to do for the mayor would be ...
Discovering "the smartest thing he could do" when referring to that laughable bumblefuck is pretty much identifying the short list of things he will never do. The man is stupider than he is ugly, and that's no mean feat.
For problems like this, if the stakeholder insists on proceeding down the ill-advised path, I will try to add a configuration option to mitigate the dangerous behavior. When they come back saying "oh, no, we wish it didn't do this", (and they occasionally do) a switch-flip and they're back in business.
Any insufficiently advanced magic is just technology.
Its amazing to watch the confusion among scientists as the entire structure of the machine goes into a state of superposition with being real and not real all at the same time.
All quantum computers are real, unless declared integer.
And yet, what would the programmer do in this case? Code to spec, code as he thinks it should work, or go back to get better specs?
In a fixed price project you bet I'd do the first! I don't have time to do the correct thing (get better specs) and I'm not failing any tests on my own dime.
This is sadly true, and I've seen it a lot. When a developer is motivated by a deadline, other people's screw ups are just things that interfere with meeting that date. Any fixes will come out of the padding in the estimates, and once that padding is gone, so is the programmer's motivation to fix them. Those kinds of bugs then get quietly swept under the rug, or if they do get brought up in advance, people start arguing about who made them, who should fix them, who will test them, and in which future release will they go out to the customer.
In this particular example, the bug is egregious, and I'd expect the programmer to make the 5 minute effort to clarify the spec. The difference is that most programmers understand math well enough to catch a math error, but not every spec error is in their field of expertise. What if the mistake was in the calculation of tax, and the programmer doesn't understand the tax laws well enough to spot the error? That bug is going to sail right through every test, and the developers will deliver their perfect-to-spec-yet-still-buggy code.
The specs are never as good as the spec writers think they are.
I've been a developer (contractor and employee) for nearly 20 years and have never seen specs that clearly defined everything.
Given the spec is incomplete, and your experience, wouldn't best practice be to analyse the requirements at the start and identify those edge cases and get decisions on them before starting.
The fact is that no set of specs are ever perfect, and the dangerous fallacy is in believing that they can be made perfect. And even if you can hone and polish them to a glistening perfection today, the problem domain the design is addressing will often change between the time the specs are written and the time the software is delivered.
Specs have several kinds of errors: errors of omission, conflicting requirements, and incorrect requirements. Design activities can identify conflicts, but often can't find the others.
Way back in the early '80s when I got my degree the thing that was placed into our heads was to spend 90% of the time designing, 5% coding, and 5% testing. These days we seem to dive into coding way too early.
The figures of "90% design, 5% code" is very much tied to physical world engineering, and is valid advice when you're creating an unchangeable physical thing like a car or a bottle-forming machine. But think about how much computers have evolved in the last 30 years - it shouldn't surprise you to learn that software development methodologies have evolved as well. Unlike hardware, software is infinitely flexible, and changes can be made cheaply and continuously throughout the life of a product. So instead of spending 90% of project time on Big Design Up Front, iterative or Agile project management methodologies and flexible design methodologies such as Test Driven Development leverage the facts that the world is constantly changing, software is infinitely flexible, its design is malleable, and having fully automated tests enables rapid changes and continuous deployment. By writing a test first, you ensure that requirement (as received) is being met. Understanding that coding is a design activity (and not a construction activity - construction happens when you click "build") is key. By applying good design principles, code can be refactored from a functioning solution to an elegant design, and this activity takes place iteratively during coding.
They've been using 3D printed objects as patterns for investment casting of metal for over 20 years, since the advent of 3D printing. The problem is cast metals are often not the best solution for the end use of the part. For example, no cast metal is yet suitable for making molds or dies for high volume plastic injection molding, where it has to be extremely hard and shock resistant - P-type tool steel is the right material for molds, but I don't believe it can yet be precisely formed by casting.
However, an investment cast metal mold makes a great temporary mold or die if your production mold breaks. A company can print up and cast a mold and get their factory back on line within just a few days. The temporary mold may only last for a thousand parts, but that will often be enough to keep them on-line for the two months it takes to have a production mold made. If not, they print another and keep going.
Office365 was created for exactly one reason. It was created to convert customers from a pay-once model to a pay-as-you-go subscription model.
Who do you think Office2013's biggest competitor is? Open Office? Hardly. They're competing against the installed base of Office2010 users. They are competing against themselves. Long ago they ran out of truly useful features to add - how many users were clamoring for the ribbon bar, or Clippy? Once they improved their software engineering skills and drove out most of the bugs and security flaws, they removed all compelling reasons to upgrade. And that is cutting into their revenue stream. Subscription based software rental will keep the money taps open, but only if they can connive people into "upgrading" to it.
This change improves one thing only: Microsoft's cash flow. It was not changed out of a desire to improve upon a working product.
And you're helping sell it.
It means "ã]6". At least that's what I got after pasting it into a base 64 converter. But I'm not sure I understand it any better now.
I was afraid someone like you would reply.
It. Was. A. Joke.
Maybe he's the guy who gets all the emails that Exchange is down, and needs a reliable email client?
And what, in your expert opinion, is the right tool for the job? Back in the day I never bothered moving to pine, because I figured elm was good enough for me. (And it was.) Now I seem to spend half my workday in Outlook, and it makes me exactly every bit as productive as elm did. It's worse, actually, because these days everyone has email and it's now far too easy for the unwashed masses to cc: a status report to a hundred people who simply don't care.
If a newer tool doesn't provide a demonstrable or measurable improvement, what makes that new tool "right"? What makes the old tool "wrong"?
Soylent Green is 99% people!!
I'd also make the patent troll produce something from that patent - shit or get off the pot. If you are not using the patent, then you have no right in retaining it or using it against someone.
Actually, this is one point I'd disagree with.
If the inventor of the patent chooses to make their own widgets, are they really making their own, or are they contracting with a Chinese factory to produce them under license? Do you require the inventor to stand on the factory line and hand-assemble each and every patented widget personally? That quickly gets silly.
So the inventor can choose to make widgets themselves, they can license the ability to make widgets to other people, or they can cash out and sell the rights to license widget-making to someone else. Just like the inventor, that someone else doesn't have to make their own widgets - instead of selling widgets they can sell licenses to make widgets.
If the inventor chose the cash-out option, that's it. They struck a deal and were paid for their invention. The law ends there. They may have struck a bad deal, they may have been swindled by a fast talker on www.help-U-sell-your-patent.com, but that's just capitalism preying on the careless, and is no different from the sale of any other goods or services.
Force is a euphemism for blackmail, and it's not inaccurate when applied here. "Nice web site you got here, it'd be a shame if we had a court order you to take it down. Give us $100,000 and nothing bad will happen to it, or you risk losing a $100,000,000 in court if we win." That's force to a company that doesn't have $100,000,000 in their bank account.
Newegg's made a corporate decision that said "we don't care if it's a thousand times cheaper to settle than to risk losing a lawsuit. We have a very large pile of money, and we have promised to call every single bluff presented to us. We will never fold our hand."
Go, Newegg!
That's what I read as well. It was so over-broad that it would have covered IBM 3270 terminals, which were a mainstay of the 1970s. They probably never tried suing IBM over it.
That was the point. There are hundreds of questions on various sides, and no one answer fits them all.
The difference? Amazon didn't get caught. Yet.
Here's the counter argument. Let's say you accidentally discover a vulnerability in a bank's web site by mistyping a URL and you ended up at a different customer's account. You write up your finding, and you privately send it to the bank's security team and ask them for nothing in return other than that they act quickly to protect your account. And let's say they turn around and accuse you of hacking them under the Computer Fraud and Abuse Act, and they provide your own written report to the Secret Service as evidence against you? Who is the ethical party?
How would money alter the ethics? If you gave them the details of the flaw and asked the bank for a $1,000 reward, would that change things? What if you offered to tell the bank of the flaw in exchange for $1,000? If they don't pay, are you ethically bound to not sell the vulnerability to a third party?
What if you don't know of any specific flaw in your bank's site, but you would like to make some side money as a pen tester; so you send them a letter asking if they have a "pay for vulnerability policy", and they respond by placing a hold on your account and calling in the Secret Service? Who is acting ethically in that scenario?
What if you fear retribution so you ask this question anonymously? Are you more or less suspicious to the bank? Should they be more or less likely to seek your prosecution?
What if you exploit the vulnerability personally to view Paris Hilton's bank balance, but you don't do anything malicious to her account? What if you disclose that balance information to the tabloids? What about viewing the bank data of a non-celebrity?
And if not the bank, which third party might you sell it to? A security researcher? A competing bank? Microsoft? A hacker? Some random alias on darkode?
Different people are likely to view these behaviors differently, including banks, law enforcement, hackers, computer security professionals, lawmakers, bank customers, and the general public. Different legal cases with different judges are likely to interpret these differently, as well.
There are few clear cut lines standing out among these questions that say "here are the exact boundaries of ethical behavior."
The article quotes the professor's example of a guy who revealed a flaw to a company that they were exposing hundreds of thousands of people's financial accounts. All he did was to change the user ID in his URL to some other number, which was a different person's account. He knew that his own information was at risk, and wanted the company to fix their badly written web site.
The reward for his reporting effort was a police investigation, and the company threatened him with the liability of the costs of fixing the flaw.
Sure, many companies will take a security report and say "oh, crap!" They'll then scurry about and fix the problem. They might say thank you, they might not. But the truth is some companies are run by total douche-nozzles who respond with threats.
When it's a possibility that companies will respond by acting as completely irrational and irresponsible as this, the professor is doing the right thing by teaching the students "don't assume any good will necessarily come from what you've done." If you monetize the flaw by selling it, someone else assumes the risk. They might buy it to exploit it, or they might hope to turn it into a reward.
His advice is to avoid the conflict entirely. It's amoral, but it's very practical advice that will keep you personally out of jail.
But you have to label the fields honestly then.
"This field contains an unexploded toy firecracker."
"This field contains no mines, but many shards of jagged, rusty, pointed steel."
"This field contains anthrax spores."
Now, if I had some reason to want to scare you away from this field, I might label it "this field contains less than fifty mines per hectare." It's perfectly true, but disingenuous.
You already have every piece of information you need to make an informed decision today.
The facts are a matter of public record. Look up the FCC ID on the label on your cell phone here: http://transition.fcc.gov/oet/ea/fccid/
Now, read the documentation that was filed in order to certify that device, and find out which sets of FCC rules it falls under to see the limits it must meet. You can also see the test reports they filed proving their device complied with all applicable rules.
If that information is inadequate to make an informed decision, how does giving you one single number suddenly make you competent to evaluate the health effects of a cell phone?
Here are the real facts that should be printed on a poster at every cell phone store in San Francisco: "WARNING: The city of Oakland is home to a crackpot who has built a lucrative speaking business convincing gullible, easily scared, and/or ignorant people about the imagined risks of cellular telephone RF emissions. If you do not own a cell phone strictly because of the irrational fears she is spreading you risk being stranded in case of emergency, which has been statistically proven to be far more dangerous to your health than any anecdotal based, non-scientific study."
You quoted misleading figures that have been out of date for over five years. Analog phones had a max power output of 3 watts, but hand-held transmitters that had their antenna next to the head were always limited to one watt max. Bag phones, which were car phones in a sack, transmitted up to three watts, but the antenna was in the bag. When Motorola came out with their dual mode phone (it slid into a car-mounted bracket for power, audio, and antenna connections), it switched itself to one watt max when in handset mode.
All digital cell phone handset technologies (CDMA, GSM) transmit 1 watt or less.
Honestly, that's what most annoys me about these sorts of cases(this, GMO labelling, 'organic' labeling, etc.) The evidence for harm or harmlessness is often rather equivocal; but the relevant trade association pressure groups scream like babies at the idea that customers would even be in the position to make an informed decision(foolish or otherwise).
Because it's ludicrous. Consider the same idea applied to a packaged cookie: "our whole wheat cookies contain less than 0.0001% arsenic, less than 1 picogram of lead, fewer than 15 anthrax spores per cookie, no more than 150 million viable microbes, below 72,000,000 mold spores," etc. The world is filled with trace amounts of stuff that humanity has ingested since the dawn of our species. It's only recently that we've even been able to recognize and measure it. And those are scientifically proven harmful ingredients at higher levels. We have standards that limit them.
The only people these numbers serve or placate are homeopaths, a completely self-deluded group of liars, charlatans, and idiots who do not deserve the respect you would afford a dead possum lying on the side of a road.
Here's the deal: if you want to know how much potentially harmful X is in a product, read the label. The information is already there, you just have to do your own research. Concerned about RF? There's an FCC ID printed on the case of your phone. Look up their filing. Read the relevant parts of the requirements they comply with pertaining to maximum allowable transmitted power. Read health studies of double blind experiments. It's all public information. But there is no way you should be spreading your irrational fears on someone else's product labels.
It's science, bitches. You want to believe in made up shit? Go to a fracking church, and close the doors behind you.