Now, when there is a security breach, there will be one standard format of personal data for criminal and intelligence agencies to process. This will streamline the process of mass identity theft and dissident profiling and improve efficiency.
The new DTP standard will no doubt include a recommended machine learning front-end to easily allow organizations to slurp up people's information in a standardized way, correlate identities across different services, and target them with advertising, thus improving advertising revenue. When users allow the 'share my data with 3rd parties' option, now there will be a standard format for the data to be shared, allowing a greater proliferation of services ready to consume it.
Yeah. I think it's not so much just the 20 years, it's just that I remember how *cool* everything felt when slashdot was new, and in comparison everything really feels old now.
Insofar as the Intel Compute Card was a solution looking for a problem, this might be a problem it could be a solution for, though a little more heavy-weight then just taking a SD card or USB stick.
>> Their goal was to make a system capable of mimicking the knowledge and intuition of human security analysts so that attacks can be detected in real time.
Did they manage to avoid mimicking all the foolishness and gullibility of human security analysts, too?
>> The platform can go through millions of events per day and can make an increasingly better evaluation of whether they are anomalous, malicious or benign.
So, based on this, it sounds like the 'quality' of the service depends on parsing data supplied by (hostile) outside sources. If the system cannot tell when people are deliberately poisoning its knowledge base with feints and false messages, then what? Human supervision? If it needs human security analysts anyways, how much does it gain?
A system needs to be able to remember what it is supposed to forget in order to make sure it is forgotten.
Imagine a waiter robot that is supposed to go into a room and make sure it gets everyone's order: a) Enters room, goes from person to person, asks drink preferences. b) John Doe tells robot: "I don't want you to track my preferences. Forget everything about me!" c) Robot obeys and continues on. d) Prior to exiting the room, the robot verifies it has gotten everyone's preferences. e) Robot sees John Doe. Robot has no record of John Doe because it has forgotten everything about John Doe. The robot must get the preferences of everyone in the room. f) Robot asks John Doe for his drink preferences. g) Goto b).
The systems have to remember that they aren't allowed to (re)learn the data that they are supposed to have forgotten, which means they cannot completely forget things - the information is always there.
> Meanwhile the W3C has installed a task force to rapidly...
Whoa whoa... hold on there. What version of the task force did they install? It is compatible with the current W3C? (It runs on Linux, right?) Is the source for the task force available? Is it running in the cloud somewhere as a virtual task force?
Unfortunately, the Gamilon advanced planet bomb base on Pluto is hidden with a concealment field, so it is unlikely the New Horizons probe will be able to provide targeting information.
During an acquisition, the company being acquired helpfully passed along the list of AS they used in their BGP4 configurations in their core routers.
They helpfully had included the ones from other networks they provided connectivity to as well, but just had sent the AS numbers over in one big list, unlabeled, along with the AS their network originated: "Do these."
So during the network integration I dutifully entered the entire list of AS into the core routers as AS to be originated. Needless to say, hilarity ensued.
So perhaps not entirely my fault - though I should, in hindsight, have asked for more clarification or done more investigation rather than blindly trusting the information I had been given. This was a couple decades ago, and I was not cynical enough yet.
What springs to mind maybe they're using code from a third party (i.e. video codecs, HDMI/DRM management, etc.) and *that* third party is not open source (for whatever definition of 'open' you prefer.)
If, (let me stress again, if) that's the case, then providing Intel with an open source solution that works better *might* resolve the issue.
It's not that great software developers never make mistakes, it's just that by knowing they can and will happen to anyone, they can try to catch them early.
It's the people who think the code they write is flawless that tend to have the most problematic code.
With regards to the actual posted question, you should find out if the company has any sort of insurance policy relating to data/security breaches that might be dictating things like the password policy. If the company has insurance to cover problems from insurance company X, and insurance company X is saying "You must do passwords, and like this, or else no insurance!", then you have a monumental task ahead of you because you have to convince your workplace to address the insurance policy/company - as well as an internal political/technical/budgetary issues.
Beyond that, the field of the business was not specified. It is possible that, depending on the country, industry, business contracts, and local regulations, there might be some specific clause dictating this corporate policy. (There can be no end to the insanity when you have a situation where, in order to do business with government and/or company Y, your own business must get certified to follow practices according to standard Z, be audited, etc.) If something like a password policy change requires a (re)audit of to verify your company's power level is still over ISO 9000, or Sigma Mane Six or whatever, well... good luck.
Given that people are essentially Google's product, or the source of it in terms of information, it makes business sense the Google would be interested in protecting the flock so the company can continue to shear the sheep regularly.
It would be more worrisome if Google found a way to have the dead be more profitable than the living and decided it should go into the mutton business.
People come up with theories, they get refined, debugged, and eventually tagged as a release candidate.
If the theories seem solid enough, there is a major/product release as something which is solid enough for other people to use in production environments.
As people keep using it, it gets minor patches/revisions. If people find a serious enough flaw/bug, then people start working on creating another major version release (or competing product.)
And, just as in software, if the new version of the theory/science is not backwards compatible to the previous one, there is much wailing and gnashing of teeth.
The change log is a product. It needs to be reviewed, readable to the target customers, and compliant to any necessary contractual, legal, or regulatory disclosures with the appropriate disclaimers. It should not reveal any trade secrets, third party confidential information, violate any vendor NDAs, have any unprofessional remarks about the customers, etc.
It sounds like the problem is you're putting out crap change logs using an automated system to copy things from the issue management system. Do you have policies in place to make sure people don't put crap into the issue management system? Are things being reviewed before the change logs are being put out? Is it being vetted by the necessary product/legal/regulatory folks to make sure nothing is in there that is going to bite you?
If a company published a crap product, then it will get bitten. When a company gets bitten, it's instinctive reaction is to stop putting out change logs to stop getting bitten, because that's the easy, lazy, doesn't take more effort answer. Asking "Whether or not change logs are a good idea?" is the wrong question. The right question is more "Okay, we got bitten because we put out crap change logs. How do we stop putting out crap?"
The answer to that question is generally something called 'Hard Work'. If the company isn't willing to put in the effort to make a good change log (appropriate policies to capture the relevant changes, tech writer/tech doc support to clean it up, manager-level review to vet it for compliance, etc.) Then, yes, it may make more business sense to not publish anything rather than to publish garbage. It's not a matter of whether or not change logs are good or bad -- good change logs are good, bad change logs are bad. The question is: How do you generate good change logs?
Think it was John Brunner's "The Shockwave Runner", which had the phrase: "There are two kinds of fools -- one who says this is old and therefore good, and the other which says this is new and therefore better."
However, as the summary points out, the end user must pay $35 to challenge "strikes" against them, and while they are refunded the full amount, if they win, there is nothing else won, nor is the ISP punished for false claims. In other words, the user assumes all risk even if they know that they are innocent.
Maybe. If the $35 if refunded in the full amount to the end user, who is paying for the arbitration service? If the ISP's detection system erroneously flags a few thousand people, and each of the claims has to be considered, some one is going to be paying for the man-hours of the arbitration work. It's not clear who is bearing the risk of the costs of false claims.
While this seems a bit poorly thought out, if (and only if) it makes the parents *legally* responsible for anything objectionable their children might find, not the ISPs, not other websites, etc., but leaves all the responsibility squarely on parental supervision, then I could get behind this. Shielding ISPs and web hosting companies from frivolous lawsuits from stupid, irresponsible parents is actually positive.
If, if (and only if) it puts the 'think of the children' squarely on the responsibility of the parents while offering them the tools/filters/guidance to supervise computer use, that could be good. Less "How could you put that up where children might find it?" and more "Why are you not being responsible for your children's activities? You were warned, given the tools, shown how to watch them. Why are you not responsible?"
If this does not provide any additional legal protections for ISPs or such from stupid parents, then, no. This is worthless.
Slashdot Mirror
Now, when there is a security breach, there will be one standard format of personal data for criminal and intelligence agencies to process. This will streamline the process of mass identity theft and dissident profiling and improve efficiency.
The new DTP standard will no doubt include a recommended machine learning front-end to easily allow organizations to slurp up people's information in a standardized way, correlate identities across different services, and target them with advertising, thus improving advertising revenue. When users allow the 'share my data with 3rd parties' option, now there will be a standard format for the data to be shared, allowing a greater proliferation of services ready to consume it.
(Yes, this is mild sarcasm.)
You know, "This one weird trick can save you from silent career killers! Just sign up for our seminar, hire our career coach, etc. to learn more."
Definitely can ruin your life.
Yeah. I think it's not so much just the 20 years, it's just that I remember how *cool* everything felt when slashdot was new, and in comparison everything really feels old now.
Insofar as the Intel Compute Card was a solution looking for a problem, this might be a problem it could be a solution for, though a little more heavy-weight then just taking a SD card or USB stick.
I'll be shocked when I can believe the virtual reality business is a real thing instead of just hype.
The Mythical Man Month - Frederick P. Brooks, Jr.
Death March (2nd Edition) - Edward Yourdon
>> Their goal was to make a system capable of mimicking the knowledge and intuition of human security analysts so that attacks can be detected in real time.
Did they manage to avoid mimicking all the foolishness and gullibility of human security analysts, too?
>> The platform can go through millions of events per day and can make an increasingly better evaluation of whether they are anomalous, malicious or benign.
So, based on this, it sounds like the 'quality' of the service depends on parsing data supplied by (hostile) outside sources. If the system cannot tell when people are deliberately poisoning its knowledge base with feints and false messages, then what? Human supervision? If it needs human security analysts anyways, how much does it gain?
Speaking of IPv6 'features' - was any solution to IPv6 multihoming actually rolled out?
Using sodium ions?
So, they would be (re)charged with "a salt in battery"?
A system needs to be able to remember what it is supposed to forget in order to make sure it is forgotten.
Imagine a waiter robot that is supposed to go into a room and make sure it gets everyone's order:
a) Enters room, goes from person to person, asks drink preferences.
b) John Doe tells robot: "I don't want you to track my preferences. Forget everything about me!"
c) Robot obeys and continues on.
d) Prior to exiting the room, the robot verifies it has gotten everyone's preferences.
e) Robot sees John Doe. Robot has no record of John Doe because it has forgotten everything about John Doe. The robot must get the preferences of everyone in the room.
f) Robot asks John Doe for his drink preferences.
g) Goto b).
The systems have to remember that they aren't allowed to (re)learn the data that they are supposed to have forgotten, which means they cannot completely forget things - the information is always there.
If it was based on a Robert Ludlum novel, the movie would obviously be written as a Jason Bourne Shell Script.
> Meanwhile the W3C has installed a task force to rapidly ...
Whoa whoa... hold on there. What version of the task force did they install? It is compatible with the current W3C? (It runs on Linux, right?) Is the source for the task force available? Is it running in the cloud somewhere as a virtual task force?
Unfortunately, the Gamilon advanced planet bomb base on Pluto is hidden with a concealment field, so it is unlikely the New Horizons probe will be able to provide targeting information.
During an acquisition, the company being acquired helpfully passed along the list of AS they used in their BGP4 configurations in their core routers.
They helpfully had included the ones from other networks they provided connectivity to as well, but just had sent the AS numbers over in one big list, unlabeled, along with the AS their network originated: "Do these."
So during the network integration I dutifully entered the entire list of AS into the core routers as AS to be originated. Needless to say, hilarity ensued.
So perhaps not entirely my fault - though I should, in hindsight, have asked for more clarification or done more investigation rather than blindly trusting the information I had been given. This was a couple decades ago, and I was not cynical enough yet.
Has anyone found out *why* Intel is doing this?
What springs to mind maybe they're using code from a third party (i.e. video codecs, HDMI/DRM management, etc.) and *that* third party is not open source (for whatever definition of 'open' you prefer.)
If, (let me stress again, if) that's the case, then providing Intel with an open source solution that works better *might* resolve the issue.
It's not that great software developers never make mistakes, it's just that by knowing they can and will happen to anyone, they can try to catch them early.
It's the people who think the code they write is flawless that tend to have the most problematic code.
With regards to the actual posted question, you should find out if the company has any sort of insurance policy relating to data/security breaches that might be dictating things like the password policy. If the company has insurance to cover problems from insurance company X, and insurance company X is saying "You must do passwords, and like this, or else no insurance!", then you have a monumental task ahead of you because you have to convince your workplace to address the insurance policy/company - as well as an internal political/technical/budgetary issues.
Beyond that, the field of the business was not specified. It is possible that, depending on the country, industry, business contracts, and local regulations, there might be some specific clause dictating this corporate policy. (There can be no end to the insanity when you have a situation where, in order to do business with government and/or company Y, your own business must get certified to follow practices according to standard Z, be audited, etc.) If something like a password policy change requires a (re)audit of to verify your company's power level is still over ISO 9000, or Sigma Mane Six or whatever, well... good luck.
Given that people are essentially Google's product, or the source of it in terms of information, it makes business sense the Google would be interested in protecting the flock so the company can continue to shear the sheep regularly.
It would be more worrisome if Google found a way to have the dead be more profitable than the living and decided it should go into the mutton business.
People come up with theories, they get refined, debugged, and eventually tagged as a release candidate.
If the theories seem solid enough, there is a major/product release as something which is solid enough for other people to use in production environments.
As people keep using it, it gets minor patches/revisions. If people find a serious enough flaw/bug, then people start working on creating another major version release (or competing product.)
And, just as in software, if the new version of the theory/science is not backwards compatible to the previous one, there is much wailing and gnashing of teeth.
The change log is a product. It needs to be reviewed, readable to the target customers, and compliant to any necessary contractual, legal, or regulatory disclosures with the appropriate disclaimers. It should not reveal any trade secrets, third party confidential information, violate any vendor NDAs, have any unprofessional remarks about the customers, etc.
It sounds like the problem is you're putting out crap change logs using an automated system to copy things from the issue management system. Do you have policies in place to make sure people don't put crap into the issue management system? Are things being reviewed before the change logs are being put out? Is it being vetted by the necessary product/legal/regulatory folks to make sure nothing is in there that is going to bite you?
If a company published a crap product, then it will get bitten. When a company gets bitten, it's instinctive reaction is to stop putting out change logs to stop getting bitten, because that's the easy, lazy, doesn't take more effort answer. Asking "Whether or not change logs are a good idea?" is the wrong question. The right question is more "Okay, we got bitten because we put out crap change logs. How do we stop putting out crap?"
The answer to that question is generally something called 'Hard Work'. If the company isn't willing to put in the effort to make a good change log (appropriate policies to capture the relevant changes, tech writer/tech doc support to clean it up, manager-level review to vet it for compliance, etc.) Then, yes, it may make more business sense to not publish anything rather than to publish garbage. It's not a matter of whether or not change logs are good or bad -- good change logs are good, bad change logs are bad. The question is: How do you generate good change logs?
Ah, right. Thanks.
Think it was John Brunner's "The Shockwave Runner", which had the phrase: "There are two kinds of fools -- one who says this is old and therefore good, and the other which says this is new and therefore better."
Pity they can't make this work as a captcha -- harnessing the power of all the spammers instead of the gamers to solve the problem.
However, as the summary points out, the end user must pay $35 to challenge "strikes" against them, and while they are refunded the full amount, if they win, there is nothing else won, nor is the ISP punished for false claims. In other words, the user assumes all risk even if they know that they are innocent.
Maybe. If the $35 if refunded in the full amount to the end user, who is paying for the arbitration service? If the ISP's detection system erroneously flags a few thousand people, and each of the claims has to be considered, some one is going to be paying for the man-hours of the arbitration work. It's not clear who is bearing the risk of the costs of false claims.
While this seems a bit poorly thought out, if (and only if) it makes the parents *legally* responsible for anything objectionable their children might find, not the ISPs, not other websites, etc., but leaves all the responsibility squarely on parental supervision, then I could get behind this. Shielding ISPs and web hosting companies from frivolous lawsuits from stupid, irresponsible parents is actually positive.
If, if (and only if) it puts the 'think of the children' squarely on the responsibility of the parents while offering them the tools/filters/guidance to supervise computer use, that could be good. Less "How could you put that up where children might find it?" and more "Why are you not being responsible for your children's activities? You were warned, given the tools, shown how to watch them. Why are you not responsible?"
If this does not provide any additional legal protections for ISPs or such from stupid parents, then, no. This is worthless.