I don't know much about this case but depending on the level of concern, even just plugging the device into a safe, isolated machine and performing an image may be insufficient.
You could imagine a USB device that presented as a harmless file store unless certain conditions were detected, in which case the device could re-present as a keyboard (providing pre-programmed keystrokes) or potentially a bluetooth or wireless network receiver that could log or analyze traffic to a hidden partition.
I think the question of how to safely analyze suspect USB devices, at the level of potential nation-state actors, needs a lot more consideration and probably some custom tooling.
I'll agree with you that modern HTML and CSS for presentation is best-of-breed. I'll accept that the DOM API is sufficient.
But neither of those necessitate JavaScript; JS is just a language that happens to run in the browser and has DOM API bindings (and the other browser APIs too). There's no reason those identical bindings couldn't be provided in any other language.
I have to encourage you not to give up on all tech interviews. (By that I think you mean "hands-on"/"practical" type tests).
I do hiring for our agency, which consists entirely of non-rock-stars, at non-rock-star pay, solving non-rock-star problems, in non-rock-star time. We still do practical tests for all interviews. Some people, actually, do just get up and walk out. I wish they'd at least look.
We do problems on the level of "fizz-buzz" or similar. Quick 10-20 minute problems. We don't make full completion a binary success/failure metric. We just want to hear you discuss your thought process and see that you're aware of variables, if statements, and for loops. Because, yeah, turns out some candidates who claim years of programming experience ... aren't.
But no tricks. And we also make sure the request is suitable to the resume (think about it as resume validation). So we wouldn't say "Python person, write a method for us in C#" or vice-versa. Smart people can easily cross-train themselves once the job starts. It's more about finding someone who has the fundamentals and can apply them.
In conclusion, I would defend the hands-on "tech" interview as necessary and not even evil.
Related question: what online sites, if any, are better to purchase items to avoid counterfeit?
I've been thinking of using B&H instead of Amazon for
electronic stuff, assuming that their reputation means they are less likely to enable counterfeit sellers, but I don't know that for sure. I also don't know if other online sites (jet.com?) have or don't have the counterfeit issue.
I found very interesting that the sample meal shown was very, very heavily pure meat. Today's meals tend to include substantial "bread"/starch component for each meat: whether a bun, breaded chicken, potatoes. That appears absent or much reduced on this menu.
What I really want is to the ability to optionally select the shipper... UPS, FedEx, USPS, OnTrac, with different prices as needed. I think a lot of people who have trouble with one particular shipping company in their area (which one varies by area) would enjoy the ability to choose the one that is more reliable, and be willing to pay for it.
I agree. Of course, there is a "spin-up" time and we prefer to select the competent candidate with skill in our tools vs the competent candidate with skill in a different tool; but absolutely a competent developer should be able to adapt to any environment.
Interviews can help accommodate this by allowing the candidate to solve a coding test in a language of their choice, while also inquiring about the candidate's learning plans. (Want to make sure they are willing to adapt to the team's tools and not try to force the team to adapt to them!)
I took a job once where the code base was in a FORTRAN-derivative language. I had never used FORTRAN or anything like it. Not a problem. I studied the code. I studied the docs. I figured it out and did the work. I would expect nothing less of any other competent developer.
Another job had a toolchain based on NodeJS on the server-side. Never used NodeJS. Not a problem. Studied the code. Studied the docs. You know the story.
The key skill is a developer's willingness and ability to learn the tools that are desired for the job at hand, and to accept and learn new tools when the time is right.
This is an oversimplification. The average household has several kinds of debt, and generally debt should be paid down in descending order of interest rate.
More significantly, investment income opportunities need to have their interest rate (or equivalent) assessed. For example, in the past 12 months, the DIA has risen 18%. Thus, if 12 months ago I had money to spare, it would have been better to put the money into DIA rather than make an extra principal payment on the mortgage, unless my mortgage is 18% or more.
With the exception of bonds and CDs, it's not possible to know the investment growth in advance, so that creates some risk of course.
There was an HN thread a week ago [0] wherein Google indicated they were using new metrics to identify and remove "terror content". The metrics include input from a variety of groups. One of the top HN comments said, "Those groups have very specific agendas. They shouldn't be allowed to block articles which disagree with their agenda." [1]
Although it could have been coincidence, it does seem like Google is making a statement with the temporary suspension of Peterson's account that these initiatives are clearly targeted at users posted politically incorrect content.
It's possible that a new version could have a breaking policy change. For example, all our intranet apps are served over HTTP. At some point, that's going to become untenable due to the changes for browser security requirements.
In general, there's no momentum to make a change that the agency doesn't "have" to make, and when the browser finally refuses to transmit forms over HTTP then we want to know about it before the change is deployed to all the users.
The login problem was attempted to be solved by Mozilla's "persona", now deprecated. I like the general idea that I strongly authenticate to my browser, which can then "vouch" for me to various sites using cryptographic tokens that are otherwise useless (so no cracking/stealing passwords, etc). The devil of course would be in the details.
Stories like this are frustrating and a symptom of the impact very large companies can have on multiple facets of our lives.
One possible approach is to keep accounts separate for personal and each business that you are involved with. For example, you probably have at least a separate personal checking account and business checking account. Likewise, it would make sense to have all accounts used for a given business to only be used for that business.
In addition to providing some safety against automated action, division of accounts provides a nice legal line, wherein if a court order requires you to disclose information, you can simply dump everything on the account without touching any of the other businesses or personal documents.
Stymieing this, of course, is companies (Facebook?) that have a policy of prohibiting a single real person from having distinct accounts.
Great article. A few years ago (at a previous job) I took a sick day for "sanity", but told them I wasn't feeling well. I felt guilty about doing it. I think part of it is the association of sick leave with externally visible medical issues, and the corresponding "straightforward" medical verification.
In other words, if you have a temperature or are vomiting, that's obvious. Many infections or physical injury can be trivially verified by a doctor. But a "sanity day", as truthful and necessary as it might be, is neither of those.
Out of curiosity, I checked my current employment contract. It says sick leave is for "A personal illness, injury or medical disability that prevents the employee from performing his or her job, or personal medical or dental appointments." or "Exposure of the employee to contagious disease when attendance at work would jeopardize the health of others." There's a dozen or so other cases listed in the contract, mostly about allowing sick leave to care for sick family members/children. Our contract also allows for verification, "If the Employer suspects abuse, the Employer may require a written medical certificate for any sick leave absence."
I've never heard of anyone here being asked for a verification, but it would tend to discourage people doing the "sanity day" sort of thing.
This is plausible, but I still have a few concerns. EV will need battery replacement on some routine basis. How will that effect the TCO and lifetime of the vehicle? One of the advantages of gas vehicles is that I can buy a vehicle very cheap and operate it for many many years. Furthermore, I can park it outside (it doesn't need to be in a garage). I expect and usually see lifespan of 20 years and 200,000 miles on gas vehicles.
It seems like there are still too few EVs to fully understand their lifespan and long-term maintenance costs (including battery replacement).
I also want to see how fast "fast charging" will be and what kind of adverse impact it has on the battery. Is it acceptable to the usability and lifespan of the vehicle to routinely charge on fast chargers? I don't want to sit at the charging station for 45 minutes when a gas car can be fully fueled in 5 or less.
At home, my expectation is that a vehicle does not need a garage, so charging at home may present a logistical challenge (OR, weather-proof outside charging stations might also be deployed). Likewise for apartments and condos with shared parking.
I think all these issues can be overcome, but they will need some thoughtful approaches to ensure that EVs are reasonable for as many people as possible to own and use, not just the wealthy.
What about the interpretation that if reality is a computer simulation, certain operations (such as the factoring described) are a form of a security weakness in the simulation, allowing the simulation to "escape" and access/consume host computational resources?
I wonder if the environment of experience is significant? USDS positions itself like a startup (even their page has a section on "dress code" which mentions being like "any other startup"). Someone whose experience is primarily enterprise or BigCo might be less appealing. It would be interesting to see a roster of current USDS FTEs and their backgrounds (I didn't see a "Who's Who" on their page, but didn't look extensively).
How do we know that the recipient of the key in your scenario (or the originator of the CSR) is in fact the domain owner? The domain contains contact information, but the exchange can't be done by email - that's not secure. Can't be done by SMS - that's not secure. We don't know them personally, so there's no obvious out-of-band technique that can be used.
We'd have to go back to physical snail mail using the address on the domain record, and/or notarization. Both of which of non-automated and very slow (relatively speaking).
You could imagine a USB device that presented as a harmless file store unless certain conditions were detected, in which case the device could re-present as a keyboard (providing pre-programmed keystrokes) or potentially a bluetooth or wireless network receiver that could log or analyze traffic to a hidden partition.
I think the question of how to safely analyze suspect USB devices, at the level of potential nation-state actors, needs a lot more consideration and probably some custom tooling.