First off, how is the agency unilaterally denying the request preferable to having the opinion of a neutral judge ruling on whether the request is covered/exempt? In your suggestion, they make that determination on their own authority whereas in the latter they have to present a legal/factual justification for their position.
Second, the agency may actually want to have the request adjudicated by a court rather than by their own fiat so it can having binding precedent if another individual files a substantially similar request in the future. In that case, they can deny the request with citation to the existing legal authority on the matter.
The lawsuits generally ask judges to rule that the records being sought do not have to be divulged. They name the requesters as defendants but do not seek damage awards.
Unless of course the judges are correct that, under current law/caselaw, the records being sought are exempt from disclosure. I mean, to me that really seems like a fact-based inquiry into each set of records and countervailing lawsuit that is the fundamental crux here.
Or to put it another way, I believe the following statements concurrently:
(1) If agencies are filing lawsuits trying to prevent disclosure of documents that clearly covered by the various (Federal, State, local) FOIAs, they should be sanctioned for frivolous lawsuits as the OP suggests.
(2) If the agencies are filing lawsuits trying to prevent the disclosure of documents that are clearly not covered by the relevant FOIA, the court should grant their request and remind the requesters not to file frivolous FOIA requests. As noted/quoted in TFA, they aren't seeking monetary damages, just a ruling telling the filers to go away.
(3) If the sought-after disclosure is neither obviously covered nor exempt from disclosure, then the court should rule on it in the context of those specific facts. I'm sure that there are finer points of FOIA law that either the filers or the agency could reasonably be wrong about and would need to be corrected. That's what the courts are for (I thought).
I'm really surprised that any of these statements would be controversial. I'm not surprised, however, that both sides of the debate would try to lump everything together into an ideological uniformity instead of wanting to delve into the fact-specifics about whether a particular record is covered or exempt under some (probably complicated) law.
Oh come on, at least use boost::filesystem -- which anyway looks on-track to be part of C++20 standard libraries.
I assume you're smart enough to re-implement a filesystem library even though Boost already did it. And then you're smart enough to extend it to cover all the cases. Smart enough to fix any subtle bugs that come up. And you'll end up in the same place that they ended up with -- with a library that deals with all the platform-specific filesystem details and abstracts it up into a nice interface with common idioms.
I (cordially) disagree that the thrust of the comment was about privacy rather than user choice. The OP wrote
Neither of those require giving up private information for a product. Do we need facial rec. to unlock a stupid phone? Heck, no. You could easily come up with a dozen, quick means to unlock a phone, that did not involve privacy violation.
What I wrote in rebuttal was that this OP statement was factual untrue. The user is not required to do anything -- the phone setup process (since we aren't using that other word) gives a choice on which authentication method to use and subtly guided towards privacy-protecting ones.
If the "onboarding" does involve sending your data to Apple, that's pretty harsh and should be called out in these discussions.
Similarly, the user is given a choice of creating an account with Apple or not. So the response is the same as that to the OP: the process involves the user choosing whether to send data to the mothership or not.
I think the net of the discussion is that technology should not be forcing users to give up their private data but rather should be letting users users chose whether, for example, to use FaceID or not. To that extent, I asked the OP if he'd ever actually gone through the phone setup process on an iPhone to see for themselves how it actually works in practice. That seems like an eminently fair ask: to be aware of the facts before pronouncing judgment.
Who said the process was completely private? I didn't even touch that point -- only an orthogonal point that the process gives the user a choice on whether or not to enable biometrics.
And a sly note that the process also steers users towards privacy protection by discouraging no/weak passcodes while still preserving the user's choice in the matter.
Neither of those require giving up private information for a product.
Neither does the iPhone. Honest question, have you ever gone through the actual on-boarding process on an iPhone? There's a pretty clear choice:
(1) Do you want to use $BIOMETRIC (replace with TouchID/FaceID)? (2) Do you want to set a passcode?
(YES) --> Passcode Setup (chose from 6-digit numeric, unbounded-length alphanumeric or 4-digit numeric)
(Enter a weak passcode like 1234) --> This is easily guessable. Are you sure?
(NO) --> This is a bad idea and leaves all your private data unprotected. Are you sure?
So aside from the fact that the user is presented with choices at every step of the way, they are also warned (but allowed to override the warning and continue) about choices like "no passcode" or "1111" that leave their privacy unprotected.
So we can assume this method was deliberately chosen to invade the privacy of users
By giving them the choice of biometric + passcode, passcode only or no protection they have had their privacy invaded? What in the world happened to the ethos of building things and letting the user chose?
What if they made an app, but it was also compatible with the web? Sort of like a web browser with an address bar and other stuff, but in addition to the functionality offered by traditional HTML/JS it also supported a handful of other protocols.
And then, a few of them could get together into some kind of forum and standardize a bit so that those other protocols could be shared. And then maybe they realize that they could also share the application too (since anyway the protocol is standardized) and ship it to customers as a one-stop web-browser-and-more that supports all your favorite gmail/slashdot/clownporn sites.
Because that's sort of what happened right -- if you want to argue that they shouldn't call it a "browser" but should call it a "whatever-marketing-thing-plus-integrated-browser", then I'm fine to concede the point because it trivializes the actual debate over technology to a silly argument over names.
And of course, if you don't want to run a WMTPIB, don't. The web hasn't changed here, your non-EME-compatible browser can still access stuff. The only thing that changed is that someone built an app that combines support for a new standard with a web browser.
"It sounds to me like it's not disconnecting, regardless of what it says."
No, it definitely disconnects (and won't reconnect) to the network that you are currently associated to.
"When I turn something off, I'd like it to be off and to remain off until such time as I turn it back on again."
That is still true. If you turn it off (switch in Settings) then it is. You still have the choice to do this.
I think the point is that it is reasonable to infer that users don't actually want the behavior of "stay off even if I'm right next to my super-high-quality home WiFi network until I remember to hit this button that I already forgot about". So the conclusion was
Keep the user choice of whether to use the 'disconnect currently associated' or 'really turn off' by having different UI elements for each one. Put the UI element that we think is more useful in a more accessible place, just like always. No UI puts all the buttons in every possible screen . . .
I'm (really am) sorry to hear that you are working on a project that must target multiple Ones but is not built on a platform that handles whatever path-utility functions you need. That sounds like a kind of serious software engineering problem, one that you have to pay for with your sweat-the-details shit of managing it in the application layer.
I'm curious though why you would say that you have to develop a common library. There should be one ready to go in the appropriate language.
Anyway, I'm grateful to work in a more sane development environment. Keep fighting the good fight and trying to get people to start new things in a modern/portable fashion.
PS. If you are doing things that cannot be composed out of path.join and path.split (with the added constraint of only using ASCII encoded things in between) then I think we're beyond "path utility" and into 'filesystem utility" -- things like creating/following soft-links and other OS-dependent gunk.
Really? Because as a developer, I would think you would use the path utilities from a library to manipulate things like filenames and directory paths. Not sure why you would ever need to think (let alone curse about) what the separator is for a particular OS when you can call path.join or path.split and let it be someone else's problem.
most people turn off the radios because they want to save non-removable battery life/quote.
Sure, but the question is whether they want it to go back to associating with known networks automatically later or whether the user should have to manually manage something the device can handle autonomously.
Because it seems like users want to turn it off to save battery during the day but also don't want to go home and then burn cellular data despite being in range of their own WiFi network because they forgot to set it back.
Maybe that's because the UI designers believe that the vast majority of users intended the former and not the latter and so they prioritized putting the frequent-intent button in a more convenient place and the infrequent-intent one further away. In fact, that's precisely the job of UI designers is to provide access to the most-used things closer without having massively overloaded UI, especially on a phone.
[ BTW, not knocking wget here. That GUI is intended for the kind of people that use wget, which are happy to have lots of buttons. ]
That depends on what you infer (or divine really) is the user's intended outcome from hitting the button.
I don't think the user intent (insofar as non-technical users have well-formed notions of intent, which is far from clear) when hitting the button is "I want to disabled WiFi connectivity but keep the ability to AirDrop".
Let's play a game, which is guess-what-the-user-actually-wants
(1) Disable all WiFi until I hit the button again, even after I get back at home so that I rack up cellular bills
(2) Disable all WiFi except for AirDrop and a bunch of other things I don't quite understand
(3) Get me off $CURRENT_WIFI (e.g. coffeeshop, airport) but do reconnect to my home network when I get back there even if I forget to hit the button
I think there's a lot of reasons to believe that the user's intended outcome is (3) rather than (1) or (2). YMMV, and I agree this is something of an imprecise science.
You can turn it off, it's there in a clear-as-day slider in Settings.
And the button doesn't say off. It's a blue button that turns gray and says "disconnected" when you've, uh, disconnected. And in my dictionary, disconnected does not redirect to "off".
One of the Bluetooth vulnerabilities cited as a motivation for turning BT off actually was fixed in every release subsequent to 9.3.5.
But, I mean, you do you -- if you really think having to go to Settings to power off the radio is so bad that you are willing to forego this (and many other) security fix(es), go for it. We won't feel bad if you get pwned by a long-since-patched bug though.
The takeaway is that if you want to really and completely turn off Bluetooth and Wi-Fi on iOS11 you can't do it from the Control Center anymore, you'll have to do it through the Settings app.
So the takeaway is that there is still a UI element that powers the radio off and the only thing changed is that a different UI element performs a disconnect rather than a power off. So a power-user that knows precisely which of the two she intends can pick the right one.
Calling it 'stupid' is a bit of an overreaction to what is basically a UI change to map a more-commonly-held button on what is perceived to the more-commonly-intended outcome. Maybe that attribution of intended outcome is wrong (as anyone that has tried to help less technical people, trying to figure out what someone is actually trying to do is a hell of a thing) but it seems at least reasonable to me that "get me off this shitty coffeeshop WiFi but do associate with my home WiFi when I get there" is a more common intent than "don't get on any network whatsoever until I remember to hit the button again".
Uhuh. Stop using the most popular libraries on the web to switch for something no one has ever heard of.
I don't care one bit about unsupported versions of IE. But rewriting vast parts of the web to fix something that isn't at all broken, no one has time for that . . .
Anything cross-site should be blocked - scripts, images, style sheets... I don't care. Host it on your own server or proxy it or it shouldn't display.
So instead of each site that uses jQuery pointing to the same (https) googleapis.com URL, every site should keep a copy of it. That means the browser would download the entire 150kB (minified) script for each site embedded the library instead of downloading it once and using the cache-control HTTP header to control caching. This will be excellent for bandwidth and load times. My understanding is that modern browsers have JS interpreters that keep hot code in a JIT cache as well to save CPU cycles rebuilding the IR.
So yeah, this proposal won't fly, especially on mobile where downloading and storing another 150KB per site is a real non-starter.
Except that the Circuit often read each other's opinions and have some chance to be persuaded by them. That is, just because they aren't binding precedent doesn't mean they can be persuasive precedent. So all told it's somewhat more likely that the 1CA will follow her sister circuits than if they were the first to review it.
(1) Anyone that claims that he or she "knows and understands all the code touching the data", is either Torvalds-level-genius or, more likely, regular-smart but completely delusional about the complexity in layers that they don't understand.
Software engineering is a team sport. The network driver guy doesn't need to know about the details of the optimizing compiler, he needs only to understand the formal contract about what constitutes a well-defined program in the language. The silicon engineering team doesn't need to understand how the UI elements are drawn, the need only to understand what functionality they need to provide to the composite. This isn't silo-ing for no reason, it's the only way to build anything of scale using people of merely-above-average intelligence.
(2) This is nonsense: "secured assets in a place where it isn't touching the eye candy web app nonsense". The whole point of most applications is to take secured assets and make them available over the web or, gasp, even mutated over the web. Taken serious, you wouldn't be able to build a web interface to access my bank account or make an online payment -- IOW, you would destroy most of the functionality we are trying to secure.
Yes, these guys were incompetent. But the answer isn't in anything you wrote.
There's your problem right there. Security demands simplicity.
A properly designed & implemented MVC is far simpler to understand, develop and audit than a tangle of spaghetti code that mixes everything up into a unitary blob.
Simplicity is not the lack of internal structure, it's the lack of complicated relationships between the various pieces. There are plenty of very complex pieces of software that are nevertheless simple because the complexity is well matched by modular design and clean/legible interfaces.
For a lot of design tasks, MVC is a proper choice for this. And like most things, using an off-the-shelf framework is largely preferable to rolling your own. That doesn't mean that some crap contractor never used it in the wrong place or wrote it completely pants-on-head stupidly. Or that some framework isn't shit.
Amazon pays sales tax on total revenue, not profit, in all 50 United States. And presumably (correct me if I'm wrong) pay the applicable VAT on all items sold in Europe. This, by the way, is one major way to stop companies from playing silly games. Let's compare for a moment:
(1) Tax consumption: reasonably straightforwards. If an item is sold for X, the tax is some rate time X, perhaps depending the category of goods. A VAT is almost as simple and can be considered in the same category. There is less[1] scope to be creative about numbers because the tax is derived straight from the purchase price. There is much less scope to be creative about geography because the location of consumption is usually super-evident.
(2) Tax profits: horrendously complicated because you don't know how to attribute the total profits of the company to each input and output. I think it's fairly clear, for instance, that there is no "scientific" way to figure out how much of the profit on (e.g.) an iPhone is due to the various inputs: software engineering, hardware engineering, IP, marketing, copyright, brand loyalty, etc. I don't even think it's a meaningful question, to be honest. The subjectivity allows for creativity in answering it, both in the numerical and geographic sense.
It's also complicated because for companies with an ecosystem of many integrated products, the total profit is more than the contribution of each individual parts because they are meant to work together. The profit from buying an IBM storage solution might be partially attributable to their success in the HPC division if customers of the latter have an easy path to adopting the former.
We've got to reform our tax systems to adopt the kind of rules that simply don't allow for creative accounting. In the meantime, we pretty much actively encourage this sort of nonsense (and doubled down in many cases) by insisting on this structure.
Consumers are not their customers. Their customers are banks and other entities that want to know whether a person is a good credit risk.
Insofar as they injured any other third parties, they should surely be held liable. But this has nothing to do with whether the individuals whose data was leaked are "customers" of the credit agency. They are clearly not, nor should such a designation even be relevant when assessing liability.
they want to customize, they want features, they want control
just like Chrome, except slower and with more bugs
Did it occur to you that the former might be one possibly cause of the latter? Because the design goals of "Loaded with features that have a million different options and permutations that the user can control" and "performant and bug free" seem to me totally at odds.
Every new feature adds (usually) bugs, degrades (some) performance and (surely) consumes engineering resources that could be spent on stability. And then, you get to allocate testing resources to the new feature to find and polish it, testing resources that could be spent elsewhere.
The same is true for the proliferation of user-controlled options. And the complexity burden is not just linear, each option can potentially impact every use case with every other option and every other feature, so you can quickly end up with an explosion of possibilities. True story, I once worked with folks that had designed a library with more than 400 possible configuration values in a file somewhere. Assuming each one was just a boolean (in fact, some were enumerations), that means the had 2**400 potential ways configurations that the library could be run. For reference, there's less than 2**270 atoms in the whole universe.
None of this is to say that "features" or "customizability" are not worthy goals. Just like none of this implies that "performance", "stability" or "lack of bugs" are not worthy goals. But if you are engaged in the actual act of building software, you have to acknowledge that those goals are at odds and that you have finite resources with which to develop, test and refine software.
Slashdot Mirror
First off, how is the agency unilaterally denying the request preferable to having the opinion of a neutral judge ruling on whether the request is covered/exempt? In your suggestion, they make that determination on their own authority whereas in the latter they have to present a legal/factual justification for their position.
Second, the agency may actually want to have the request adjudicated by a court rather than by their own fiat so it can having binding precedent if another individual files a substantially similar request in the future. In that case, they can deny the request with citation to the existing legal authority on the matter.
The lawsuits generally ask judges to rule that the records being sought do not have to be divulged. They name the requesters as defendants but do not seek damage awards.
Unless of course the judges are correct that, under current law/caselaw, the records being sought are exempt from disclosure. I mean, to me that really seems like a fact-based inquiry into each set of records and countervailing lawsuit that is the fundamental crux here.
Or to put it another way, I believe the following statements concurrently:
(1) If agencies are filing lawsuits trying to prevent disclosure of documents that clearly covered by the various (Federal, State, local) FOIAs, they should be sanctioned for frivolous lawsuits as the OP suggests.
(2) If the agencies are filing lawsuits trying to prevent the disclosure of documents that are clearly not covered by the relevant FOIA, the court should grant their request and remind the requesters not to file frivolous FOIA requests. As noted/quoted in TFA, they aren't seeking monetary damages, just a ruling telling the filers to go away.
(3) If the sought-after disclosure is neither obviously covered nor exempt from disclosure, then the court should rule on it in the context of those specific facts. I'm sure that there are finer points of FOIA law that either the filers or the agency could reasonably be wrong about and would need to be corrected. That's what the courts are for (I thought).
I'm really surprised that any of these statements would be controversial. I'm not surprised, however, that both sides of the debate would try to lump everything together into an ideological uniformity instead of wanting to delve into the fact-specifics about whether a particular record is covered or exempt under some (probably complicated) law.
Oh come on, at least use boost::filesystem -- which anyway looks on-track to be part of C++20 standard libraries.
I assume you're smart enough to re-implement a filesystem library even though Boost already did it. And then you're smart enough to extend it to cover all the cases. Smart enough to fix any subtle bugs that come up. And you'll end up in the same place that they ended up with -- with a library that deals with all the platform-specific filesystem details and abstracts it up into a nice interface with common idioms.
But is that software development or masochism?
Fair enough, thanks - these threads get so toxic.
I (cordially) disagree that the thrust of the comment was about privacy rather than user choice. The OP wrote
Neither of those require giving up private information for a product. Do we need facial rec. to unlock a stupid phone? Heck, no. You could easily come up with a dozen, quick means to unlock a phone, that did not involve privacy violation.
What I wrote in rebuttal was that this OP statement was factual untrue. The user is not required to do anything -- the phone setup process (since we aren't using that other word) gives a choice on which authentication method to use and subtly guided towards privacy-protecting ones.
If the "onboarding" does involve sending your data to Apple, that's pretty harsh and should be called out in these discussions.
Similarly, the user is given a choice of creating an account with Apple or not. So the response is the same as that to the OP: the process involves the user choosing whether to send data to the mothership or not.
I think the net of the discussion is that technology should not be forcing users to give up their private data but rather should be letting users users chose whether, for example, to use FaceID or not. To that extent, I asked the OP if he'd ever actually gone through the phone setup process on an iPhone to see for themselves how it actually works in practice. That seems like an eminently fair ask: to be aware of the facts before pronouncing judgment.
Who said the process was completely private? I didn't even touch that point -- only an orthogonal point that the process gives the user a choice on whether or not to enable biometrics.
And a sly note that the process also steers users towards privacy protection by discouraging no/weak passcodes while still preserving the user's choice in the matter.
Neither of those require giving up private information for a product.
Neither does the iPhone. Honest question, have you ever gone through the actual on-boarding process on an iPhone? There's a pretty clear choice:
(1) Do you want to use $BIOMETRIC (replace with TouchID/FaceID)?
(2) Do you want to set a passcode?
(YES) --> Passcode Setup (chose from 6-digit numeric, unbounded-length alphanumeric or 4-digit numeric)
(Enter a weak passcode like 1234) --> This is easily guessable. Are you sure?
(NO) --> This is a bad idea and leaves all your private data unprotected. Are you sure?
So aside from the fact that the user is presented with choices at every step of the way, they are also warned (but allowed to override the warning and continue) about choices like "no passcode" or "1111" that leave their privacy unprotected.
So we can assume this method was deliberately chosen to invade the privacy of users
By giving them the choice of biometric + passcode, passcode only or no protection they have had their privacy invaded? What in the world happened to the ethos of building things and letting the user chose?
What if they made an app, but it was also compatible with the web? Sort of like a web browser with an address bar and other stuff, but in addition to the functionality offered by traditional HTML/JS it also supported a handful of other protocols.
And then, a few of them could get together into some kind of forum and standardize a bit so that those other protocols could be shared. And then maybe they realize that they could also share the application too (since anyway the protocol is standardized) and ship it to customers as a one-stop web-browser-and-more that supports all your favorite gmail/slashdot/clownporn sites.
Because that's sort of what happened right -- if you want to argue that they shouldn't call it a "browser" but should call it a "whatever-marketing-thing-plus-integrated-browser", then I'm fine to concede the point because it trivializes the actual debate over technology to a silly argument over names.
And of course, if you don't want to run a WMTPIB, don't. The web hasn't changed here, your non-EME-compatible browser can still access stuff. The only thing that changed is that someone built an app that combines support for a new standard with a web browser.
It is just you.
"It sounds to me like it's not disconnecting, regardless of what it says."
No, it definitely disconnects (and won't reconnect) to the network that you are currently associated to.
"When I turn something off, I'd like it to be off and to remain off until such time as I turn it back on again."
That is still true. If you turn it off (switch in Settings) then it is. You still have the choice to do this.
I think the point is that it is reasonable to infer that users don't actually want the behavior of "stay off even if I'm right next to my super-high-quality home WiFi network until I remember to hit this button that I already forgot about". So the conclusion was
Keep the user choice of whether to use the 'disconnect currently associated' or 'really turn off' by having different UI elements for each one. Put the UI element that we think is more useful in a more accessible place, just like always. No UI puts all the buttons in every possible screen . . .
I'm (really am) sorry to hear that you are working on a project that must target multiple Ones but is not built on a platform that handles whatever path-utility functions you need. That sounds like a kind of serious software engineering problem, one that you have to pay for with your sweat-the-details shit of managing it in the application layer.
I'm curious though why you would say that you have to develop a common library. There should be one ready to go in the appropriate language.
Anyway, I'm grateful to work in a more sane development environment. Keep fighting the good fight and trying to get people to start new things in a modern/portable fashion.
PS. If you are doing things that cannot be composed out of path.join and path.split (with the added constraint of only using ASCII encoded things in between) then I think we're beyond "path utility" and into 'filesystem utility" -- things like creating/following soft-links and other OS-dependent gunk.
Really? Because as a developer, I would think you would use the path utilities from a library to manipulate things like filenames and directory paths. Not sure why you would ever need to think (let alone curse about) what the separator is for a particular OS when you can call path.join or path.split and let it be someone else's problem.
most people turn off the radios because they want to save non-removable battery life /quote.
Sure, but the question is whether they want it to go back to associating with known networks automatically later or whether the user should have to manually manage something the device can handle autonomously.
Because it seems like users want to turn it off to save battery during the day but also don't want to go home and then burn cellular data despite being in range of their own WiFi network because they forgot to
set it back.
Maybe that's because the UI designers believe that the vast majority of users intended the former and not the latter and so they prioritized putting the frequent-intent button in a more convenient place and the infrequent-intent one further away. In fact, that's precisely the job of UI designers is to provide access to the most-used things closer without having massively overloaded UI, especially on a phone.
[ BTW, not knocking wget here. That GUI is intended for the kind of people that use wget, which are happy to have lots of buttons. ]
That depends on what you infer (or divine really) is the user's intended outcome from hitting the button.
I don't think the user intent (insofar as non-technical users have well-formed notions of intent, which is far from clear) when hitting the button is "I want to disabled WiFi connectivity but keep the ability to AirDrop".
Let's play a game, which is guess-what-the-user-actually-wants
(1) Disable all WiFi until I hit the button again, even after I get back at home so that I rack up cellular bills
(2) Disable all WiFi except for AirDrop and a bunch of other things I don't quite understand
(3) Get me off $CURRENT_WIFI (e.g. coffeeshop, airport) but do reconnect to my home network when I get back there even if I forget to hit the button
I think there's a lot of reasons to believe that the user's intended outcome is (3) rather than (1) or (2). YMMV, and I agree this is something of an imprecise science.
You can turn it off, it's there in a clear-as-day slider in Settings.
And the button doesn't say off. It's a blue button that turns gray and says "disconnected" when you've, uh, disconnected. And in my dictionary, disconnected does not redirect to "off".
If you tap the wifi or bluetooth buttons to turn them off, the blue highlight turns gray and the text in the larger display will say "disconnected".
That sounds to me like a disconnect button.
One of the Bluetooth vulnerabilities cited as a motivation for turning BT off actually was fixed in every release subsequent to 9.3.5.
But, I mean, you do you -- if you really think having to go to Settings to power off the radio is so bad that you are willing to forego this (and many other) security fix(es), go for it. We won't feel bad if you get pwned by a long-since-patched bug though.
The takeaway is that if you want to really and completely turn off Bluetooth and Wi-Fi on iOS11 you can't do it from the Control Center anymore, you'll have to do it through the Settings app.
So the takeaway is that there is still a UI element that powers the radio off and the only thing changed is that a different UI element performs a disconnect rather than a power off. So a power-user that knows precisely which of the two she intends can pick the right one.
Calling it 'stupid' is a bit of an overreaction to what is basically a UI change to map a more-commonly-held button on what is perceived to the more-commonly-intended outcome. Maybe that attribution of intended outcome is wrong (as anyone that has tried to help less technical people, trying to figure out what someone is actually trying to do is a hell of a thing) but it seems at least reasonable to me that "get me off this shitty coffeeshop WiFi but do associate with my home WiFi when I get there" is a more common intent than "don't get on any network whatsoever until I remember to hit the button again".
Uhuh. Stop using the most popular libraries on the web to switch for something no one has ever heard of.
I don't care one bit about unsupported versions of IE. But rewriting vast parts of the web to fix something that isn't at all broken, no one has time for that . . .
Anything cross-site should be blocked - scripts, images, style sheets... I don't care. Host it on your own server or proxy it or it shouldn't display.
So instead of each site that uses jQuery pointing to the same (https) googleapis.com URL, every site should keep a copy of it. That means the browser would download the entire 150kB (minified) script for each site embedded the library instead of downloading it once and using the cache-control HTTP header to control caching. This will be excellent for bandwidth and load times. My understanding is that modern browsers have JS interpreters that keep hot code in a JIT cache as well to save CPU cycles rebuilding the IR.
So yeah, this proposal won't fly, especially on mobile where downloading and storing another 150KB per site is a real non-starter.
Except that the Circuit often read each other's opinions and have some chance to be persuaded by them. That is, just because they aren't binding precedent doesn't mean they can be persuasive precedent. So all told it's somewhat more likely that the 1CA will follow her sister circuits than if they were the first to review it.
(1) Anyone that claims that he or she "knows and understands all the code touching the data", is either Torvalds-level-genius or, more likely, regular-smart but completely delusional about the complexity in layers that they don't understand.
Software engineering is a team sport. The network driver guy doesn't need to know about the details of the optimizing compiler, he needs only to understand the formal contract about what constitutes a well-defined program in the language. The silicon engineering team doesn't need to understand how the UI elements are drawn, the need only to understand what functionality they need to provide to the composite. This isn't silo-ing for no reason, it's the only way to build anything of scale using people of merely-above-average intelligence.
(2) This is nonsense: "secured assets in a place where it isn't touching the eye candy web app nonsense". The whole point of most applications is to take secured assets and make them available over the web or, gasp, even mutated over the web. Taken serious, you wouldn't be able to build a web interface to access my bank account or make an online payment -- IOW, you would destroy most of the functionality we are trying to secure.
Yes, these guys were incompetent. But the answer isn't in anything you wrote.
Model-View-Controller (MVC) framework for Java
There's your problem right there. Security demands simplicity.
A properly designed & implemented MVC is far simpler to understand, develop and audit than a tangle of spaghetti code that mixes everything up into a unitary blob.
Simplicity is not the lack of internal structure, it's the lack of complicated relationships between the various pieces. There are plenty of very complex pieces of software that are nevertheless simple because the complexity is well matched by modular design and clean/legible interfaces.
For a lot of design tasks, MVC is a proper choice for this. And like most things, using an off-the-shelf framework is largely preferable to rolling your own. That doesn't mean that some crap contractor never used it in the wrong place or wrote it completely pants-on-head stupidly. Or that some framework isn't shit.
Amazon pays sales tax on total revenue, not profit, in all 50 United States. And presumably (correct me if I'm wrong) pay the applicable VAT on all items sold in Europe. This, by the way, is one major way to stop companies from playing silly games. Let's compare for a moment:
(1) Tax consumption: reasonably straightforwards. If an item is sold for X, the tax is some rate time X, perhaps depending the category of goods. A VAT is almost as simple and can be considered in the same category. There is less[1] scope to be creative about numbers because the tax is derived straight from the purchase price. There is much less scope to be creative about geography because the location of consumption is usually super-evident.
(2) Tax profits: horrendously complicated because you don't know how to attribute the total profits of the company to each input and output. I think it's fairly clear, for instance, that there is no "scientific" way to figure out how much of the profit on (e.g.) an iPhone is due to the various inputs: software engineering, hardware engineering, IP, marketing, copyright, brand loyalty, etc. I don't even think it's a meaningful question, to be honest. The subjectivity allows for creativity in answering it, both in the numerical and geographic sense.
It's also complicated because for companies with an ecosystem of many integrated products, the total profit is more than the contribution of each individual parts because they are meant to work together. The profit from buying an IBM storage solution might be partially attributable to their success in the HPC division if customers of the latter have an easy path to adopting the former.
We've got to reform our tax systems to adopt the kind of rules that simply don't allow for creative accounting. In the meantime, we pretty much actively encourage this sort of nonsense (and doubled down in many cases) by insisting on this structure.
[1] And amusing discussions about whether Jaffa cakes are biscuits or cookies or whether a Snuggie is a blanket or a robe.
Consumers are not their customers. Their customers are banks and other entities that want to know whether a person is a good credit risk.
Insofar as they injured any other third parties, they should surely be held liable. But this has nothing to do with whether the individuals whose data was leaked are "customers" of the credit agency. They are clearly not, nor should such a designation even be relevant when assessing liability.
they want to customize, they want features, they want control
just like Chrome, except slower and with more bugs
Did it occur to you that the former might be one possibly cause of the latter? Because the design goals of "Loaded with features that have a million different options and permutations that the user can control" and "performant and bug free" seem to me totally at odds.
Every new feature adds (usually) bugs, degrades (some) performance and (surely) consumes engineering resources that could be spent on stability. And then, you get to allocate testing resources to the new feature to find and polish it, testing resources that could be spent elsewhere.
The same is true for the proliferation of user-controlled options. And the complexity burden is not just linear, each option can potentially impact every use case with every other option and every other feature, so you can quickly end up with an explosion of possibilities. True story, I once worked with folks that had designed a library with more than 400 possible configuration values in a file somewhere. Assuming each one was just a boolean (in fact, some were enumerations), that means the had 2**400 potential ways configurations that the library could be run. For reference, there's less than 2**270 atoms in the whole universe.
None of this is to say that "features" or "customizability" are not worthy goals. Just like none of this implies that "performance", "stability" or "lack of bugs" are not worthy goals. But if you are engaged in the actual act of building software, you have to acknowledge that those goals are at odds and that you have finite resources with which to develop, test and refine software.