I am actually sympathetic to the idea of an exemption for raw public data sets not for human consumption. Today the default is HTTP and you have to have a good reason to go HTTPS. The goal here is to flip the default and get people thinking in terms of HTTPS by default. There is always room for exceptions from the rule. A use case like this seems like a reasonable exception. But the risk here is that the purpose or scope of the site changes. Maybe next year they're hosting raw data sets about something more politically charged, and a researcher in a country whose government doesn't like that kind of research could find herself with unwanted attention simply for accessing that public raw data set. Alternatively, someone decides to tamper with that data set in flight. Or someone decides to dual-purpose the site for some reason and serve content to people, forgetting that it isn't an HTTPS site, in which case we're where we are today.
Please read my comment as dealing with this particular axis of tax policy. Obviously, not everyone in the EU wants the EU to be like the US in all respects. It is also wrong to suggest that no one in the EU wants to be like the US in any respect.
Please follow up at https://github.com/WhiteHouse/.... We are keen to understand these issues and find solutions. We also do know a thing or two about web hosting and HTTPS.
On one hand, the EU wants to be more like the US: Create an EU internal market (http://en.wikipedia.org/wiki/Internal_market). Open the borders for trade and business. Let companies set up shop in a single EU state and sell to anyone in any other EU member state without having to do a mess of paperwork, currency conversions, or taxes (aside from VAT). On the other hand, some EU states see other EU states doing things to attract business, and they see their tax revenues going somewhere else, and they want to fix that. EU seems to be in this situation where it has competing goals and competing feelings on how taxes should work and I'm really interested to see how they reconcile that. Either each country needs to be able to operate and tax independently, or they need to work together as a single cohesive union and stop trying to perpetuate their pre-union tax schemes. In many respects this feels like a US state getting upset that a company in the next state over is selling to its people and the other state is getting all of the income tax revenue. Can you imagine what it would be like if you had to deal with income taxes in every US state in which you did business?
(Granted, this is somewhat independent of the whole Bermuda thing, but usually when people complain about these tax avoidance schemes it's about Ireland or something.)
The "additional CPU" nowadays for SSL is fairly trivial. If you've done some experiments that demonstrate a meaningful performance impact, and you can quantify the costs of that, we'd LOVE your feedback so that we can help you mitigate that or convince you that the benefits are worth the costs. We'd like to see data here.
Likewise with the caching issue. The use of CDNs can mitigate some of the performance impact you're worried about. If you're working with a specific scientific project or experiment where you need to shuttle around a lot of data, and are presently using HTTP and HTTP caching solutions to implement that, I would propose there are better ways of efficient data distribution. Again, submit an issue at the link above about this and someone can work with you to talk about your situation.
The IDS problem can be solved by moving the SSL termination to the other side of your IDS. It's not necessary for the origin server to serve HTTPS. It can also be resolved by changing your approach to IDS to one that doesn't require inspection of the payload at a distance from where it's served.
We do see privacy incidents routinely due to someone thinking "gosh, I didn't expect that would be private" or "I forgot to move that to the https site". We also routinely see ISPs and governments inject ads and tracking mechanisms into HTTP responses. We are also just simply concerned about the privacy and safety of people that browse government web sites and by standardizing on HTTPS everywhere, it eliminates the need for these mistakes and oversights and ensures a minimum bar for privacy and data integrity. It also makes it super easy to be FISMA compliant without having to spend extra to lock down a particular feature or product.
Please raise your concerns with the link given above and let's chat.
Privacy is in the eye of the individual. Is the location of an AIDS clinic private information? No, but the fact that you're looking for that information could be intensely private. Is the location of a US embassy private? Job postings? Things we think of as non-private information here could get you detained or worse if your Internet connectivity is monitored by an oppressive government. We want the information on government web sites to be useful and for people to feel safe and comfortable accessing.
Who do you trust to make those judgment calls? Every one of a thousand government contractors building your web sites? Or does it make more sense to just standardize on HTTPS everywhere and simplify your world?
And this doesn't even begin to cover the cases of ISPs injecting ads or tracking or worse into your HTTP responses, which happens all the time.
FWIW, just because the NSA does something doesn't mean every other government employee or agency approves or is culturally aligned with that attitude. This effort represents a genuine push by a self-selected group that is privacy-conscious, interested in doing the technically right thing, and for the first time in a position within the government to actually start making the Right Thing reality. Interested in joining us?
If there are specific concerns you have with the memo as it applies to the federal agencies it's talking about, we'd love to get your feedback on how we can achieve these goals while minimizing the issues you allude to.
This isn't about mandating HTTPS everywhere outside of government, and those agency sites that might perform worse due to losing intermediate caches can always implement the policy using existing CDNs to try and get the content as close to the user as possible.
Is there something about what the memo proposes that looks to be obsolete soon? We're trying to get ahead of the curve here, because it does take time to change things in the government. We'd love to better understand your "when the government gets involved" concerns.
Do you think you might be interested in participating in things like this on a more ongoing basis?
Developers should grossly outnumber operations. If it doesn't, your ops people probably aren't doing enough automation. Depending on how important that scalability and automation is, you might want more "devops" types in your operations team than other companies. Truly large tech companies call this SRE and don't have a traditional ops role at all. So I'd say having your three-way split would be OK for some companies, but a two-way split between non-ops developers and dev-ops operations works well for others. Really anything that minimizes the rigid wall between the two sides and gives each visibility and influence into the other is good.
I think the idea is to *find* good people that already have interests and skills that encompass the union of the two, and supplement the "good developers doing development" and "good operation guys doing operation stuff".
To be honest, I think a developer that has no interest in infrastructure is a developer that can't design a scalable, supportable service (you need to know how the infrastructure works in order to effectively use it). An ops person that has no interest in programming is an ops person that can't scalably support a service (who's going to build the automation and monitoring?). In my eyes a good balance is to have your "good developers doing development" supplemented with some "developers that know operations" to make sure they're designing things well. On the operations side, supplement "developers that know operations" with "operations people that know how to code" so they can work together to scale up automation, not staff, as a service grows. This is essentially how SRE works at many large tech companies.
For a better idea of why "reversible" matters, and experimental evidence suggesting that if you do reverse the effect of the interaction, you can restore quantum behavior, check out http://en.wikipedia.org/wiki/D....
You're misunderstanding the OP's point, I think. You and I don't think to ourselves, "let's store a history of our journey in our spin!" We just remember it. We perceive ourselves to be macroscopic classical systems. We have learned, however, that quantum effects can apply to macroscopic objects (as the OP points out, the C60 molecule most recently). Since your mind is simply a product of the arrangement of the molecules and energy in your brain, the implication is that while you would perceive yourself behaving classically (moving through one "slit"), if you were sufficiently isolated from outside observers to prevent decoherence, you would actually be behaving non-classically from their perspective. We just can't perceive that because decoherence is a local thing and our brains are a classical arrangement of matter.
Another way to think about it: decoherence is the process of the observer becoming entangled with the system being observed. Since perception is classical, a classical result is observed and the observer reacts accordingly. But if the system + local observer are isolated from a second observer, the pair are just another quantum system and decoherence occurs a second time when the second observer interrogates the first. Until the second decoherence happens, the observer is in a superposition of states--each state being a classical observer who has just observed different things, unaware of the other state.
Taking this back to the post the OP is responding to, "consciousness" doesn't matter. The nature of the "observer" doesn't matter. That it's even an observation is a concept we made up to relate our perception to the world we perceive. It's just fundamentally thermodynamic interaction.
I think for the most part you are right. However, if the customer knows he is exploiting an error on their web site to get a product at an unreasonably low price (bad faith), I believe the merchant would have grounds to contest the transaction and could be entitled to reverse it, even if it's completed and even if the customer has a receipt in hand. That being said, "Merchant Makes Error, Sues Customers" isn't a flattering headline.
He is still obligated to deliver them, at the price he charged
I don't believe this is true; the merchant can issue a refund pretty much at any time and cancel the deal. If the merchant was paid, but hasn't performed his obligation, he can't really be *compelled* to. That's essentially slavery. You always have the right to breach a contract. If the other party was harmed by your breach, they also have the right to sue you to get compensated for that harm. It's unlikely that the average person is going to be harmed much more than the money they sent the merchant, so a refund is entirely reasonable compensation.
That's not how I read it, but that would make more sense, I suppose. I'm thinking of situations where you have a multi-pronged attack, and one prong accesses one set of sensitive data, and the other prong accesses another. One access may be discovered, the clock starts, and 72 hours later they may not even be far enough into their forensics to find out about the other prong of the attack. But if you're defining each as its own "breach", even though it's part of the same larger complex attack, I suppose it's a little more reasonable than I interpret it.
But what if you're investigating something like this:
1. Breach of data A occurs 2. First breach of data B occurs (small set of data accessed) 3. Second breach of data B, by the same attacker from a different attack vector, occurs (accessing more data)
1 is discovered, clock starts, but you're able to get a full report out after 72h. 2 is discovered, separate clock starts, and you're able to get that report out after 72h. 3 is discovered. Should that have been part of (2)? What happens if you don't notice this during your investigation of (2)?
Your post suggests you've never done this before. Consider:
1. Spear phishing attack nets the credentials of employee A. 2. A's credentials are used to access sensitive data B. A normally has access to B so this doesn't set off any alarms. 3. A's credentials are used to plant malicious code on an internal web site. 4. Malicious code nets credentials of employee C and D and E (and a dozen others). 5. A separate attacker probes C's access, digs through source code repository. 6. Source code review yields an exploitable vulnerability in an internal system. 7. Staging from D's workstation, internal system F is cracked using discovered vulnerability. This gives them access to credentials that are trusted by system G. 8. Staging from E's workstation, sensitive system G is accessed using credentials stolen from F. 9. An administrator on G notices that something is amiss.
So now that you've discovered the breach, the clock starts.
10. G contacts E to ask what's going on, but E's at home asleep. 11. E's workstation is taken offline and forensics begins. 12. The credentials stolen from F are used on several systems because the developer re-used them, so it takes a while to figure out that F was where they were stolen from. The attackers covered their tracks, but a sharp-eyed engineer found access attempts in an unrelated daemon's logs from D. 13. D is contacted, and has no explanation. It's possible he would have accessed that system, but he can't remember. But your guys are smart, so you check his system for malware just in case. 14. Malware found on D. How did it get there? He exchanges software with a 3rd party all the time, so you spend some time scanning what he's downloaded, turning up nothing, so then you go through his e-mail, and find a short e-mail with a link from a colleague that seems out of place. The URL doesn't look suspicious (the vulnerability was removed by the attackers after it was used), so you set it aside. 15. You get stuck, so you go back to that e-mail again, one item of many presumed false leads, and realize that A didn't remember sending it. 16. Malware found on A, spear phishing e-mail found. 17. Logs of systems scoured for activity from A, sensitive access to B found. 18. A's outbound e-mail checked, e-mail to C (and dozens of others) found that looks similarly suspicious. 19. Logs of systems scoured for activity from C, accesses to source code repository found. 20. The dozens of others also affected are investigated to see what systems they accessed, just in case there's more. 21. What did you miss? Was there anything else? Keep looking. Are you sure that's it? Keep looking.
This is all "best-case" and you haven't even started trying to identify the attackers yet, much less assembling a report.
It's easy to play the armchair security consultant and talk about "proper log handling and log analysis" as though that's the magic bullet. Do you think that every company subject to this law has "proper log handling and log analysis" covering every component of every internal system on their network? Do you think even a majority of companies have this?
Do you think it's typical that every system in this chain of investigation will have all of the logs needed to proceed to the next step? Do you think those doing the investigations will always have easy access to these logs? That they will spot patterns that look like normal accesses but really came from an unauthorized attacker? Do you think they will even have access to the systems in question without having to track down an administrator?
There are companies that have the forethought (or experience) to make such a forensic exercise relatively fast and accurate, but these companies are the exception, not the rule, and even for those that have their shit together, investigations like this could take WEEKS to reach a meaningful conclusion about what data was compromised. You might know *something* after 72 hours, but in many cases this will be far from a "full report".
Do they really expect every massive, multi-part intrusion to be investigated to completion so that a full report can be made after only 72 hours? What am I missing?
The advertiser and content provider are working together. The content provider wants ads on their site, and they want you to click on those ads, because the advertiser makes money, and shares that money with the content provider. The two parties have an incentive to cooperate. Both parties want those ads to be relevant to you, because that increases the chances you'll click on them.
Today, if you are known to the advertiser, but unknown to the content provider, you get shown relevant ads, but the content provider has no knowledge of who you are or what ads you were shown. This works because the content provider can embed content from the advertiser, and your browser identifies itself to the advertiser independently of the content provider by way of these cookies.
Without third-party cookies, advertisers and content providers are going to look for other ways to keep their ads relevant. The easiest way to do this is to work together to implement these as first-party cookies served by the content provider instead of the advertiser, and have the content provider share these identifiers with the advertiser, and be aware of the ads served to you. Do you think this is better or worse for privacy?
So I mostly agree with your sentiment, but the facts you're using to justify your sentiment are suspect.
Then suddenly the farmer is sued for using their GMO crops without planting.
Farmers aren't sued because their crops are tainted. Farmers are sued when they utilize the patented genes. If their crops are contaminated, but they don't actually change their approach to dealing with pests, or change how they harvest their crops, they aren't getting any of the benefit of the genes and so they aren't infringing on the patent and would prevail in a lawsuit.
You're probably alluding to the Schmeiser case here. The key thing to remember here is that Schmeiser (a) suspected that his crop was contaminated, (b) tested the contaminated plants to confirm his suspicions, (c) saved and isolated the seed in question, and (d) used that "contamination" seed to produce something like a thousand acres of crop. That was what got him in hot water, and that's why he lost against Monsanto. That wasn't about the contamination, it was about the exploitation of the (patented) traits of that crop.
A handful of companies control the worlds food seeds because of the patents on GMOs.
GMOs aren't forced onto farmers. Farmers, at any time, can decide to buy "public domain" seed and produce non-GMO crops all they want. Seed from most every conceivable crop is banked and can be purchased trivially from universities and governments. Farmers choose GMO seed because GMO seed produces more profitable crops, either because the traits sell better in the market, or because the crops have higher yields. This isn't about GMOs and patents, except to the degree that these (superior) crops wouldn't exist but for the patents that allow companies to be profitable researching and producing them.
Followed up by creating weeds that are immune to these super chemical pesticides and other regular pesticides leaving non-Monsanto farmers screwed.
This has nothing whatsoever to do with Monsanto or GMOs. Glyphosate-resistant weeds exist because they evolved to exist, exactly the same way that antibiotic-resistant bacteria exists, and being a customer of Monsanto does not mean you don't have to deal with herbicide-resistant weeds. The problem is one of poor weed control practices by the farmers. If you kill all of your weeds, with a variety of herbicides, the problem doesn't exist. If you rely entirely on a single herbicide, and allow some of the weeds to survive, you end up breeding herbicide-resistant weeds. It doesn't matter if the herbicide is Glyphosate or something more typical.
which can spread to plants they don't own and ruining those for other farmers [citation needed].
There is a spectrum of competency among H1B workers just as there is among non-H1B workers. If you are a tech company trying to hire only the smartest candidates (without regard to H1B status), more H1B candidates means a larger pool of exceptional candidates. Don't think that a difference in "averages" says anything about people in the top percentiles.
This isn't necessarily representative of all companies trying to hire STEM people. I work at a large tech company and do a tremendous amount of interviewing. The problem is not finding people with STEM backgrounds, it's with finding good people with STEM backgrounds. While "good" is subjective, and the bar may be different for different companies, if my bar is set so high that I can't hire as many people as I want to, that's still a shortage in my opinion, and one that can be addressed by more STEM education and letting me hire more H1Bs. People can be cynical all they want about hiring cheap H1B workers, but you can't argue with the fact that allowing yourself access to more candidates means you can cherrypick more superstar workers.
Yes, this is absolutely the case. I do a lot of interviewing for a major tech company, and while there is no shortage at all of STEM candidates shoving resumes in our face, very few of them meet our (admittedly high) acceptance bar. So, for us, there is indeed a shortage of qualified workers. More/better STEM education would allow smarter people to enter the industry, as would allowing more H1B visas.
Why would an intelligent shareholder be willing to pay an American CEO 400x as much as an average worker, when in the rest of the world (include Europe, Canada and Japan) they "only" earn 10x-20x as much?
If someone with proven CEO skills has a choice between companies, they're probably going to choose the one willing to pay 400x, leaving the one paying 10x-20x to take a risk on someone unproven. Even if it works out, and the cheaper CEO turns out to know what they're doing, how long are they going to stick around and work for your "intelligent" shareholders when his resume now puts him in the same league as the 400x CEOs?
Lots of people seem to be missing the point here. It's easy to be cynical and point out that companies must be doing it so they can get away with paying less for desperate H1B workers. These people do not work for tech companies trying to hire good people. There is no shortage of candidates with STEM backgrounds and education, which is all this study seems to say. I have done literally hundreds of interviews at a large tech company for software/systems engineers, and meet an endless supply of STEM candidates all the time. The problem is that the vast majority of them do not meet our hiring bar. If you need to hire 100 software engineers, but can only 50 that meet the company's high hiring standards, that kind of sounds like a shortage to me. Sure, we can hire 50 mediocre software engineers to get to 100, but why would I want to do that? I'd much rather see better STEM education and H1B flexibility (in that order) so that I can fill those other 50 positions with good people.
Slashdot Mirror
I am actually sympathetic to the idea of an exemption for raw public data sets not for human consumption. Today the default is HTTP and you have to have a good reason to go HTTPS. The goal here is to flip the default and get people thinking in terms of HTTPS by default. There is always room for exceptions from the rule. A use case like this seems like a reasonable exception. But the risk here is that the purpose or scope of the site changes. Maybe next year they're hosting raw data sets about something more politically charged, and a researcher in a country whose government doesn't like that kind of research could find herself with unwanted attention simply for accessing that public raw data set. Alternatively, someone decides to tamper with that data set in flight. Or someone decides to dual-purpose the site for some reason and serve content to people, forgetting that it isn't an HTTPS site, in which case we're where we are today.
Please read my comment as dealing with this particular axis of tax policy. Obviously, not everyone in the EU wants the EU to be like the US in all respects. It is also wrong to suggest that no one in the EU wants to be like the US in any respect.
Please follow up at https://github.com/WhiteHouse/.... We are keen to understand these issues and find solutions. We also do know a thing or two about web hosting and HTTPS.
On one hand, the EU wants to be more like the US: Create an EU internal market (http://en.wikipedia.org/wiki/Internal_market). Open the borders for trade and business. Let companies set up shop in a single EU state and sell to anyone in any other EU member state without having to do a mess of paperwork, currency conversions, or taxes (aside from VAT). On the other hand, some EU states see other EU states doing things to attract business, and they see their tax revenues going somewhere else, and they want to fix that. EU seems to be in this situation where it has competing goals and competing feelings on how taxes should work and I'm really interested to see how they reconcile that. Either each country needs to be able to operate and tax independently, or they need to work together as a single cohesive union and stop trying to perpetuate their pre-union tax schemes. In many respects this feels like a US state getting upset that a company in the next state over is selling to its people and the other state is getting all of the income tax revenue. Can you imagine what it would be like if you had to deal with income taxes in every US state in which you did business?
(Granted, this is somewhat independent of the whole Bermuda thing, but usually when people complain about these tax avoidance schemes it's about Ireland or something.)
Hi oneiros27, please take a look at the open issues and provide your feedback at https://github.com/WhiteHouse/...
The "additional CPU" nowadays for SSL is fairly trivial. If you've done some experiments that demonstrate a meaningful performance impact, and you can quantify the costs of that, we'd LOVE your feedback so that we can help you mitigate that or convince you that the benefits are worth the costs. We'd like to see data here.
Likewise with the caching issue. The use of CDNs can mitigate some of the performance impact you're worried about. If you're working with a specific scientific project or experiment where you need to shuttle around a lot of data, and are presently using HTTP and HTTP caching solutions to implement that, I would propose there are better ways of efficient data distribution. Again, submit an issue at the link above about this and someone can work with you to talk about your situation.
The IDS problem can be solved by moving the SSL termination to the other side of your IDS. It's not necessary for the origin server to serve HTTPS. It can also be resolved by changing your approach to IDS to one that doesn't require inspection of the payload at a distance from where it's served.
We do see privacy incidents routinely due to someone thinking "gosh, I didn't expect that would be private" or "I forgot to move that to the https site". We also routinely see ISPs and governments inject ads and tracking mechanisms into HTTP responses. We are also just simply concerned about the privacy and safety of people that browse government web sites and by standardizing on HTTPS everywhere, it eliminates the need for these mistakes and oversights and ensures a minimum bar for privacy and data integrity. It also makes it super easy to be FISMA compliant without having to spend extra to lock down a particular feature or product.
Please raise your concerns with the link given above and let's chat.
Privacy is in the eye of the individual. Is the location of an AIDS clinic private information? No, but the fact that you're looking for that information could be intensely private. Is the location of a US embassy private? Job postings? Things we think of as non-private information here could get you detained or worse if your Internet connectivity is monitored by an oppressive government. We want the information on government web sites to be useful and for people to feel safe and comfortable accessing.
Who do you trust to make those judgment calls? Every one of a thousand government contractors building your web sites? Or does it make more sense to just standardize on HTTPS everywhere and simplify your world?
And this doesn't even begin to cover the cases of ISPs injecting ads or tracking or worse into your HTTP responses, which happens all the time.
FWIW, just because the NSA does something doesn't mean every other government employee or agency approves or is culturally aligned with that attitude. This effort represents a genuine push by a self-selected group that is privacy-conscious, interested in doing the technically right thing, and for the first time in a position within the government to actually start making the Right Thing reality. Interested in joining us?
https://www.whitehouse.gov/usd...
https://18f.gsa.gov/
If there are specific concerns you have with the memo as it applies to the federal agencies it's talking about, we'd love to get your feedback on how we can achieve these goals while minimizing the issues you allude to.
https://github.com/WhiteHouse/...
This isn't about mandating HTTPS everywhere outside of government, and those agency sites that might perform worse due to losing intermediate caches can always implement the policy using existing CDNs to try and get the content as close to the user as possible.
Is there something about what the memo proposes that looks to be obsolete soon? We're trying to get ahead of the curve here, because it does take time to change things in the government. We'd love to better understand your "when the government gets involved" concerns.
Do you think you might be interested in participating in things like this on a more ongoing basis?
https://18f.gsa.gov/
https://www.whitehouse.gov/usd...
Yes.
Join us:
https://www.whitehouse.gov/usd...
https://18f.gsa.gov/
Developers should grossly outnumber operations. If it doesn't, your ops people probably aren't doing enough automation. Depending on how important that scalability and automation is, you might want more "devops" types in your operations team than other companies. Truly large tech companies call this SRE and don't have a traditional ops role at all. So I'd say having your three-way split would be OK for some companies, but a two-way split between non-ops developers and dev-ops operations works well for others. Really anything that minimizes the rigid wall between the two sides and gives each visibility and influence into the other is good.
I think the idea is to *find* good people that already have interests and skills that encompass the union of the two, and supplement the "good developers doing development" and "good operation guys doing operation stuff".
To be honest, I think a developer that has no interest in infrastructure is a developer that can't design a scalable, supportable service (you need to know how the infrastructure works in order to effectively use it). An ops person that has no interest in programming is an ops person that can't scalably support a service (who's going to build the automation and monitoring?). In my eyes a good balance is to have your "good developers doing development" supplemented with some "developers that know operations" to make sure they're designing things well. On the operations side, supplement "developers that know operations" with "operations people that know how to code" so they can work together to scale up automation, not staff, as a service grows. This is essentially how SRE works at many large tech companies.
For a better idea of why "reversible" matters, and experimental evidence suggesting that if you do reverse the effect of the interaction, you can restore quantum behavior, check out http://en.wikipedia.org/wiki/D....
You're misunderstanding the OP's point, I think. You and I don't think to ourselves, "let's store a history of our journey in our spin!" We just remember it. We perceive ourselves to be macroscopic classical systems. We have learned, however, that quantum effects can apply to macroscopic objects (as the OP points out, the C60 molecule most recently). Since your mind is simply a product of the arrangement of the molecules and energy in your brain, the implication is that while you would perceive yourself behaving classically (moving through one "slit"), if you were sufficiently isolated from outside observers to prevent decoherence, you would actually be behaving non-classically from their perspective. We just can't perceive that because decoherence is a local thing and our brains are a classical arrangement of matter.
Another way to think about it: decoherence is the process of the observer becoming entangled with the system being observed. Since perception is classical, a classical result is observed and the observer reacts accordingly. But if the system + local observer are isolated from a second observer, the pair are just another quantum system and decoherence occurs a second time when the second observer interrogates the first. Until the second decoherence happens, the observer is in a superposition of states--each state being a classical observer who has just observed different things, unaware of the other state.
Taking this back to the post the OP is responding to, "consciousness" doesn't matter. The nature of the "observer" doesn't matter. That it's even an observation is a concept we made up to relate our perception to the world we perceive. It's just fundamentally thermodynamic interaction.
I think for the most part you are right. However, if the customer knows he is exploiting an error on their web site to get a product at an unreasonably low price (bad faith), I believe the merchant would have grounds to contest the transaction and could be entitled to reverse it, even if it's completed and even if the customer has a receipt in hand. That being said, "Merchant Makes Error, Sues Customers" isn't a flattering headline.
I don't believe this is true; the merchant can issue a refund pretty much at any time and cancel the deal. If the merchant was paid, but hasn't performed his obligation, he can't really be *compelled* to. That's essentially slavery. You always have the right to breach a contract. If the other party was harmed by your breach, they also have the right to sue you to get compensated for that harm. It's unlikely that the average person is going to be harmed much more than the money they sent the merchant, so a refund is entirely reasonable compensation.
That's not how I read it, but that would make more sense, I suppose. I'm thinking of situations where you have a multi-pronged attack, and one prong accesses one set of sensitive data, and the other prong accesses another. One access may be discovered, the clock starts, and 72 hours later they may not even be far enough into their forensics to find out about the other prong of the attack. But if you're defining each as its own "breach", even though it's part of the same larger complex attack, I suppose it's a little more reasonable than I interpret it.
But what if you're investigating something like this:
1. Breach of data A occurs
2. First breach of data B occurs (small set of data accessed)
3. Second breach of data B, by the same attacker from a different attack vector, occurs (accessing more data)
1 is discovered, clock starts, but you're able to get a full report out after 72h.
2 is discovered, separate clock starts, and you're able to get that report out after 72h.
3 is discovered. Should that have been part of (2)? What happens if you don't notice this during your investigation of (2)?
Your post suggests you've never done this before. Consider:
1. Spear phishing attack nets the credentials of employee A.
2. A's credentials are used to access sensitive data B. A normally has access to B so this doesn't set off any alarms.
3. A's credentials are used to plant malicious code on an internal web site.
4. Malicious code nets credentials of employee C and D and E (and a dozen others).
5. A separate attacker probes C's access, digs through source code repository.
6. Source code review yields an exploitable vulnerability in an internal system.
7. Staging from D's workstation, internal system F is cracked using discovered vulnerability. This gives them access to credentials that are trusted by system G.
8. Staging from E's workstation, sensitive system G is accessed using credentials stolen from F.
9. An administrator on G notices that something is amiss.
So now that you've discovered the breach, the clock starts.
10. G contacts E to ask what's going on, but E's at home asleep.
11. E's workstation is taken offline and forensics begins.
12. The credentials stolen from F are used on several systems because the developer re-used them, so it takes a while to figure out that F was where they were stolen from. The attackers covered their tracks, but a sharp-eyed engineer found access attempts in an unrelated daemon's logs from D.
13. D is contacted, and has no explanation. It's possible he would have accessed that system, but he can't remember. But your guys are smart, so you check his system for malware just in case.
14. Malware found on D. How did it get there? He exchanges software with a 3rd party all the time, so you spend some time scanning what he's downloaded, turning up nothing, so then you go through his e-mail, and find a short e-mail with a link from a colleague that seems out of place. The URL doesn't look suspicious (the vulnerability was removed by the attackers after it was used), so you set it aside.
15. You get stuck, so you go back to that e-mail again, one item of many presumed false leads, and realize that A didn't remember sending it.
16. Malware found on A, spear phishing e-mail found.
17. Logs of systems scoured for activity from A, sensitive access to B found.
18. A's outbound e-mail checked, e-mail to C (and dozens of others) found that looks similarly suspicious.
19. Logs of systems scoured for activity from C, accesses to source code repository found.
20. The dozens of others also affected are investigated to see what systems they accessed, just in case there's more.
21. What did you miss? Was there anything else? Keep looking. Are you sure that's it? Keep looking.
This is all "best-case" and you haven't even started trying to identify the attackers yet, much less assembling a report.
It's easy to play the armchair security consultant and talk about "proper log handling and log analysis" as though that's the magic bullet. Do you think that every company subject to this law has "proper log handling and log analysis" covering every component of every internal system on their network? Do you think even a majority of companies have this?
Do you think it's typical that every system in this chain of investigation will have all of the logs needed to proceed to the next step? Do you think those doing the investigations will always have easy access to these logs? That they will spot patterns that look like normal accesses but really came from an unauthorized attacker? Do you think they will even have access to the systems in question without having to track down an administrator?
There are companies that have the forethought (or experience) to make such a forensic exercise relatively fast and accurate, but these companies are the exception, not the rule, and even for those that have their shit together, investigations like this could take WEEKS to reach a meaningful conclusion about what data was compromised. You might know *something* after 72 hours, but in many cases this will be far from a "full report".
Do they really expect every massive, multi-part intrusion to be investigated to completion so that a full report can be made after only 72 hours? What am I missing?
Think this through, for a moment.
The advertiser and content provider are working together. The content provider wants ads on their site, and they want you to click on those ads, because the advertiser makes money, and shares that money with the content provider. The two parties have an incentive to cooperate. Both parties want those ads to be relevant to you, because that increases the chances you'll click on them.
Today, if you are known to the advertiser, but unknown to the content provider, you get shown relevant ads, but the content provider has no knowledge of who you are or what ads you were shown. This works because the content provider can embed content from the advertiser, and your browser identifies itself to the advertiser independently of the content provider by way of these cookies.
Without third-party cookies, advertisers and content providers are going to look for other ways to keep their ads relevant. The easiest way to do this is to work together to implement these as first-party cookies served by the content provider instead of the advertiser, and have the content provider share these identifiers with the advertiser, and be aware of the ads served to you. Do you think this is better or worse for privacy?
So I mostly agree with your sentiment, but the facts you're using to justify your sentiment are suspect.
Then suddenly the farmer is sued for using their GMO crops without planting.
Farmers aren't sued because their crops are tainted. Farmers are sued when they utilize the patented genes. If their crops are contaminated, but they don't actually change their approach to dealing with pests, or change how they harvest their crops, they aren't getting any of the benefit of the genes and so they aren't infringing on the patent and would prevail in a lawsuit.
You're probably alluding to the Schmeiser case here. The key thing to remember here is that Schmeiser (a) suspected that his crop was contaminated, (b) tested the contaminated plants to confirm his suspicions, (c) saved and isolated the seed in question, and (d) used that "contamination" seed to produce something like a thousand acres of crop. That was what got him in hot water, and that's why he lost against Monsanto. That wasn't about the contamination, it was about the exploitation of the (patented) traits of that crop.
A handful of companies control the worlds food seeds because of the patents on GMOs.
GMOs aren't forced onto farmers. Farmers, at any time, can decide to buy "public domain" seed and produce non-GMO crops all they want. Seed from most every conceivable crop is banked and can be purchased trivially from universities and governments. Farmers choose GMO seed because GMO seed produces more profitable crops, either because the traits sell better in the market, or because the crops have higher yields. This isn't about GMOs and patents, except to the degree that these (superior) crops wouldn't exist but for the patents that allow companies to be profitable researching and producing them.
Followed up by creating weeds that are immune to these super chemical pesticides and other regular pesticides leaving non-Monsanto farmers screwed.
This has nothing whatsoever to do with Monsanto or GMOs. Glyphosate-resistant weeds exist because they evolved to exist, exactly the same way that antibiotic-resistant bacteria exists, and being a customer of Monsanto does not mean you don't have to deal with herbicide-resistant weeds. The problem is one of poor weed control practices by the farmers. If you kill all of your weeds, with a variety of herbicides, the problem doesn't exist. If you rely entirely on a single herbicide, and allow some of the weeds to survive, you end up breeding herbicide-resistant weeds. It doesn't matter if the herbicide is Glyphosate or something more typical.
which can spread to plants they don't own and ruining those for other farmers [citation needed].
There is a spectrum of competency among H1B workers just as there is among non-H1B workers. If you are a tech company trying to hire only the smartest candidates (without regard to H1B status), more H1B candidates means a larger pool of exceptional candidates. Don't think that a difference in "averages" says anything about people in the top percentiles.
This isn't necessarily representative of all companies trying to hire STEM people. I work at a large tech company and do a tremendous amount of interviewing. The problem is not finding people with STEM backgrounds, it's with finding good people with STEM backgrounds. While "good" is subjective, and the bar may be different for different companies, if my bar is set so high that I can't hire as many people as I want to, that's still a shortage in my opinion, and one that can be addressed by more STEM education and letting me hire more H1Bs. People can be cynical all they want about hiring cheap H1B workers, but you can't argue with the fact that allowing yourself access to more candidates means you can cherrypick more superstar workers.
Yes, this is absolutely the case. I do a lot of interviewing for a major tech company, and while there is no shortage at all of STEM candidates shoving resumes in our face, very few of them meet our (admittedly high) acceptance bar. So, for us, there is indeed a shortage of qualified workers. More/better STEM education would allow smarter people to enter the industry, as would allowing more H1B visas.
Why would an intelligent shareholder be willing to pay an American CEO 400x as much as an average worker, when in the rest of the world (include Europe, Canada and Japan) they "only" earn 10x-20x as much?
If someone with proven CEO skills has a choice between companies, they're probably going to choose the one willing to pay 400x, leaving the one paying 10x-20x to take a risk on someone unproven. Even if it works out, and the cheaper CEO turns out to know what they're doing, how long are they going to stick around and work for your "intelligent" shareholders when his resume now puts him in the same league as the 400x CEOs?
Lots of people seem to be missing the point here. It's easy to be cynical and point out that companies must be doing it so they can get away with paying less for desperate H1B workers. These people do not work for tech companies trying to hire good people. There is no shortage of candidates with STEM backgrounds and education, which is all this study seems to say. I have done literally hundreds of interviews at a large tech company for software/systems engineers, and meet an endless supply of STEM candidates all the time. The problem is that the vast majority of them do not meet our hiring bar. If you need to hire 100 software engineers, but can only 50 that meet the company's high hiring standards, that kind of sounds like a shortage to me. Sure, we can hire 50 mediocre software engineers to get to 100, but why would I want to do that? I'd much rather see better STEM education and H1B flexibility (in that order) so that I can fill those other 50 positions with good people.
I suggest it be made very clear what data is collected and precisely how it is used.
https://developers.google.com/speed/public-dns/privacy