Slashdot Mirror

Or alternatively, something like these --

Do You See What I See? Detecting Hidden Streaming Cameras Through Similarity of Simultaneous Observation
Detecting Wireless Spy Cameras Via Stimulating and Probing
Detecting Spies in IoT Systems using Cyber-Physical Correlation
DeWiCam: Detecting Hidden Wireless Cameras via Smartphones

Or alternatively, something like these --

Do You See What I See? Detecting Hidden Streaming Cameras Through Similarity of Simultaneous Observation
Detecting Wireless Spy Cameras Via Stimulating and Probing
Detecting Spies in IoT Systems using Cyber-Physical Correlation
DeWiCam: Detecting Hidden Wireless Cameras via Smartphones

https://queue.acm.org/detail.c...

This explains it better than I ever could.

There is no "US program"

That's not entirely true.

The ACM, in conjunction with the IEEE publishes a set of common curriculum standards for post-secondary Computer Science programs. Many (most?) colleges and Universities in North America that have Computer Science programs will, at least in part, base their curriculum off the ACM/IEEE recommendations.

Being a US-centric test, it's possible that the test presumes the use of the ACM/IEEE curriculum. From what I can tell, the Major Field Test for Computer Science is designed with input from professors from several US universities, and presumably they design it around the curricula they teach and feel is important for a student to know -- and chances are very good that curricula is the ACM/IEEE curricula. If Chinese, Indian, and Russian Universities are using different curricula standards, it would absolutely introduce some form of bias.

Yaz

Maybe that's what C used to do, but as you pointed out, that PDP-11 model is long dead. C compilers are more complicated now because the computing environment and CPU designs are more complicated.

C is not close to the metal - that's largely a myth perpetuated by C hackers.

" DEDA is a new tool for Linux that researchers have created to read and decode the forensic information, and to anonymize information to protect against tracking.

The Electronic Frontier Foundation discovered in 2008 that nearly all major color laser printer manufacturers added tracking dots to any printed document. The yellow tracking dots were invisible to the eye and apparently added to printouts on request of the U.S. government."

Earlier discussion of this and more sophisticated printer tracking codes [src]

Yeah. People don't get that Microsoft have changed and they keep looking for 'malice' when there really isn't. I'm sure the Microsoft developer that built this thing had literally never heard of Gnome when they designed/built it. After all, it was initially designed to cope with the largest git repository on the planet for a team of EMPLOYEES working on a corporate owned project. They were probably thinking of one thing alone: how to make the lives of their fellow developers easier.

THAT'S IT.

(Interestingly, the other big companies out there -- Google and Facebook -- use a similar 'single repository' approach; just neither use Git source control for their main repository. Google uses Piper which is an internal-to-Google-only-tool. Facebook (at at 2014 anyway) uses Mercurial.

Remember it's coping with a 100GB pack file, 3.5M file, 4000 user repository. The Linux kernel is (at 1.5GB), by Microsoft standards, doesn't even count as a medium scale repository!

So, yeah. Lets assume that developers are developers and actually want to solve TECHNICAL problems, not this sort of argument. Even if they're in Microsoft, Facebook, Google, or even, shock horror, Oracle.

And the Slashdot crowd needs to have a good, fucking, hard look at themselves. Microsoft have used this GVFS name for this project for over a year now. It has been announced on Slashdot more than once. It took some dweeb THIS long to notice?

And that shows you how irrelevant Slashdot is - because if Slashdot was relevant, they would have triggered this reaction THE FIRST TIME.

Azure, you have the option of using a data centre that is owned by Deutsche Telecom and which Microsoft US has no access to, so you are also shielded from US law enforcement. They have also invested a lot in their Secure Cloud initiative, the prototype of which is available to select partners and uses Intel SGX to allow you to run code in Azure that Microsoft has no visibility into, even if they are running a malicious or compromised hypervisor.

This sounds like the old Microsoft: whatever you are concerned about, they promise you it's just around the corner, in the next version, in some product you can't quite afford yet but maybe later when you really really need it. Then when you try to use it, it's a piece of shit, flakey, crippled, overpromised. From Day 1 of selling incomplete DOS to IBM rather than CP/M, to their crashy operating systems and substandard compilers in the 90s, to Azure today, it's the same pattern.

How are you supposed to verify US law enforcement has no access to something? Minimum, I would like a high US court to say, "we agree this is beyond our jurisdiction," which of course they will never do because courts imagine themselves omnipotent. but I don't see how they can roll updates to it and diagnose problems with it, ie. how it can have any value-add from being "cloud", unless the Top Engineers have access to it, and those engineers are in the US where they can be coerced to execute warrants. What does it matter from whom they are renting the space?

If Intel SGX really is the magical solution to anything getting hacked by anyone, why isn't it the hottest topic at every security conference in the world? It sounds more like Earthquake Safety Paint, another old imaginary Microsoft product. I'm sure it will defend you from one class of strawman hypervisor exploits, but the class of exploits, to the platform itself, how do you defend the contents of the disk or the contents of RAM from leaking to an attacker while still supporting virtual machine booting and live migration? Suppose you have clever key infrastructure and an off-cloud root-of-trust, which they aren't discussing and probably don't have, but just suppose. Is the key kept in the users' control only so long as the cloud infrastructure is not compromised? ie., can pwnt Azure get your keys just by saying "boot token, please," to the off-cloud root-of-trust and then electing not to use [clever key infrastructure]? Can timing attacks, known plaintext attacks (including CRIME-like compress-then-encrypt attacks), recover the key or parts of the contents? And, of course, Intel backdoors are surely game-over, which are worth worrying about since they're a US/Israeli company, and which can be mitigated by air-gapped non-cloud computing, so it is rather ironic to have Intel offer some magic black-box DRM baloney as the solution to their bloatware and political vulnerability.

A Logic-in-Memory architecture for large-scale-integration technologies

A computing machine is described which is structured around a distributed logic storage device called the Processing Memory. This machine, the Brookhaven Logic-In-Memory Processor (BLIMP), is meant only as a vehicle for simulating and evaluating its concepts, rather than for eventual fabrication. In particular, it is shown that the architecture used is very well suited to large-scale-integration (LSI) implementation technologies. It was first necessary to redefine the various goals of logic design optimization in the context of LSI implementation. Then an elemental building block of the Processing Memory is described as having evolved from associative memory circuits. It is shown that a computer such as BLIMP which utilizes the Processing Memory concept can meet the goals of design optimization for LSI. Design techniques for this project were developed as they were required. Of particular importance is a simulation system called MODEL, which documents the structure and analyzes the behavior of the proposed system.

>More to the point, the only way you can achieve a 50/50 split is to leave more than two-thirds of all computer science grads completely idle, and about 81% of all male CS grads unemployed.

Who knows? Maybe this is the direction in which we're heading. The latest draft of the ACM's code of ethics has made social justice and diversity hires a positive obligation of all computing professionals.

"Computing professionals should strive to build diverse teams and create safe, inclusive spaces for all people, including those of underrepresented backgrounds."

Also: "Computing professionals should consider whether the results of their efforts respect diversity, will be used in socially responsible ways, will meet social needs, and will be broadly accessible. They are
encouraged to actively contribute to society by engaging in pro bono or volunteer work. When the interests of multiple groups conflict, the needs of the least advantaged should be given increased attention and priority."

More troubling: "leaders should encourage and reward compliance with those policies, and take appropriate action when policies are violated."

This is exactly what Google did. They awarded bonuses to people who criticized Damore on their internal fora.

View the draft here:
https://ethics.acm.org/2018-co...

You can give feedback here:
https://www.surveymonkey.com/r...
â
 

Your general point re intention is well taken. However:

A lie is an intentional deception. If you have a computer that can lie to you, it must have passed the Turing test a long time ago and may even be self-aware by now.

The Turing Test has nothing to do with intention, sentience, or sapience.

It's a philosophical proposal to illustrate the thesis that the attribute "thinking" should be applied to an entity based on pragmatic analysis - what programmers might call "black box" testing. It can be contrasted with, for example, Searle's Chinese Room, which is a philosophical proposal to argue an opposing position: that the attribute "thinking" implies some essence beyond what's observable from outside the system.

As various people (such as Robert French) have pointed out, the Turing Test is not in fact a useful test for thinking - and there's little reason to believe Turing himself thought it would be. It's purely a mental exercise: if you accept the thesis of the TT, then you accept the idea of mechanical thought; if you don't accept it, then what's your counterargument?

Of course various people - Searle, as noted above, and Penrose, and various others - have presented counterarguments. Some of them (e.g. Searle) accept the possibility of mechanical thought, but not the TT; others don't believe in mechanical thought, or (e.g. Penrose) believe that it requires a system strictly more powerful than a finite-space, finite-time approximation of a Turing Machine.

However, given all that, we might posit, say, a machine which is capable of thought and intention, but can only communicate on a single topic. Such a system would fail the TT against any reasonable set of judges, but would still be capable of lying.

"Satoshi-level crypto knowledge" isn't a very high barrier. Bitcoin was assembled from well-known algorithms and protocols. See Narayanan and Clark, "Bitcoin's Academic Pedigree".

The innovation by the inventor(s) of Bitcoin ("Satoshi") was to put those pieces together in a particular way, under a catchy name, at the right time.

Which is what most inventors do, after all; I don't want to diminish the achievement. It's not every day that someone cobbles together something a bit different out of well-known ideas and it becomes a big industry phenomenon.

But it's quite a few days.

(So could it have been Musk? It's not impossible, but it doesn't strike me as very likely.)

Do they mean (obv. I didn't read TFA) code is duplicated in non-forked code

Yes they do mean that. The summary should've mentioned this. From https://dl.acm.org/citation.cf...:

(abstract) [...] This paper analyzes a corpus of 4.5 million non-fork projects hosted on GitHub representing over 428 million files written in Java, C++, Python, and JavaScript. [...]

As for "the greatest benefit to mankind" that Nobel wanted to recognize, the list of Turing Award winners includes those who brought us personal computing, the internet, and the world wide web.

Even a single anecdote would disprove your theory of 'thousands of years'. There is no such thing as 'thousands of years' of runtime on a drive, you're talking MEAN time BETWEEN failures (or MTTDL, mean time to data loss) and even then you have to account for all the drive configurations in existence, in an ideal world.

You can do the calculations, go ahead, there are calculators on the Internet for you. There used to be an Excel spreadsheet from a Sun engineer a long time ago, but

I'm sure you won't understand the content of this article, but for reference to other people: http://queue.acm.org/detail.cf...

The Digital Library is an add-on to a normal ACM Membership that gives access to journals and publications going back decades, as well as access to a selection of modern textbooks and technical books.

It doubles the cost of the annual ACM membership, but I can think of a few times where a few hours spent reading old journals has saved me a week of hacking around because someone had previously proved a solution to a problem I was trying to solve.

The Digital Library is an add-on to a normal ACM Membership that gives access to journals and publications going back decades, as well as access to a selection of modern textbooks and technical books.

It doubles the cost of the annual ACM membership, but I can think of a few times where a few hours spent reading old journals has saved me a week of hacking around because someone had previously proved a solution to a problem I was trying to solve.

If your codebase is somehow 300GB of code..... Imagine what kind of attack surface that represents. This kind of size is about insane.....

Heh. Google's source repository was 86 PB (yes, that's 86,000,000 GB), in 2015. It's bigger now. Google uses Perforce, BTW, the thing that MS migrated away from because it ostensibly couldn't handle their puny 300 GB repo.

It should be noted that Google's source repository contains more than just source code. In particular, it contains all of the build tools, compilers, libraries, etc. so when you check out a given revision of some project and build it, you build it with the tools used to build it originally. I'm sure there are lots of other sorts of non-code resources in there as well.

You need to read the Software Engineering Code of Ethics toot sweet. Here's the link http://www.acm.org/about/se-co....

Microwave ovens do generate microwaves. Using the waves, we can:

• - see through walls: http://people.csail.mit.edu/fadel/wivi/
• - identify people: https://arxiv.org/abs/1608.03430
• - monitor heart rate and breathing patterns: http://witrack.csail.mit.edu/vitalradio
• - identify key strokes: http://dl.acm.org/citation.cfm?id=2790109

Don't be so naive.

And if you have a million?

The GP refers to the possibility that the compiler is compromised to insert evil instructions even through it's compiling good code. From Thompson's work:

"No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect."

No, it's not "the basis of high frequency trading". Sarao was not engaged in HFT. No one can conduct HFT against the Chicago Mercantile from London (if the orders are actually being made from London, as Sarao's were). The latency is much, much, much too high.

Sarao was manipulating simplistic HFT and other automatic-trading algorithms by placing and cancelling large volumes of trades in a particular direction. HFT systems place a lot of trades, but they're hedged positions, not all going in the same direction; then most of them are cancelled as soon as the price moves. In fact, it's likely real HFT systems were less vulnerable than non-HFT automatic-trading ones to Sarao's manipulations, since HFT trades are hedged and operate on a much finer time grain.

Just look at this typical story on Sarao, which claims that his process operated "hundreds of times per hour". That's not HFT. That's barely even automation speed. Even if they're off by a couple of orders of magnitude, it's still not HFT. (And it couldn't be, unless Sarao was running a C&C locally but the actual trading-terminal software was running in Chicago.)

A lot of people seem to have rather a rather simplistic understanding of HFT based on sources like Flash Boys or Automate This, which no doubt are fine middlebrow popular treatments; but for technical accuracy, it's much better to consult journal articles such as this piece from CACM .

Gestures on external (not on screen) tablet/slate/surfaces has been around for almost ever now.
http://portal.acm.org/citation...
http://users.erols.com/rwservi...
It is nothing new, nor revolutionary. Yes it has been improved a lt since the early days, but it is still the same concept.
If you can't improve something with 30 years or more of technological advance you need to take up echo-farming where no progress is acceptable and using a paperclip for a novel use is still revolutionary.

After all, if it weren't for that bug bounty enticing him....

Seriously, this guy needs a firm slap on the wrist and a year or two of probation, not prison time.

When it comes to carelessness, this ranks up there with the Robert T. Morris Sendmail worm of 1988. Heck, I'd hold Morris to a higher standard than this guy since he (Morris) was a graduate student at the time and presumably knew what he was doing more than Desai.

By the way, Morris was elected Fellow of the ACM in 2014.

References:

https://scholar.google.com/sch...

http://awards.acm.org/award_wi...

And the not-always-reliable reference, Wikipedia:

https://en.wikipedia.org/w/ind...

Yes you can do this but the leakage is actually quite significant. There is a paper from CCS last year that shows with medical records, for instance, a large fraction of the secret data is leaked when encrypted with deterministic encryption (necessary for your index). There are more advanced searchable encryption schemes that have better leakage, but at the end of the day you either settle for lesser security or have huge server overhead.

As long as you can build it youself, and the checksums match what's in the ECU, then this issue doesn't exist

Hmm, you must be new here. Please see Ken Thompson's 'Reflections on Trusting Trust' ( https://dl.acm.org/citation.cf... ) and come back once you're properly enlightened.

Artificial Intelligence is a field of study, just like Algebra.

The way ACM defines it [1], AI includes computer vision, NLP, planning, and knowledge representation and reasoning. All these tasks are today based on computational statistic/machine learning. You can also look at the last AAAI conference [2].

The way it is defined, your GPS is an AI system.

[1] http://dl.acm.org/ccs_flat.cfm
[2] http://www.aaai.org/Conference...

If you really think that, then I'd suggest that you read our recent PLDI paper: Into the depths of C: elaborating the de facto standards. We asked a load of people on the C standards committee, C developers, and C compiler writers about the semantics of various C programs and got very different responses.

I think that Google knows what it is doing

They do. But that doesn't mean that you do. What works for Google (or the DOD, or IBM) doesn't work for most other companies, projects, or programmers, because they operate under a completely different set of constraints.

As Alan Kay has said, "Computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture..."

I suggest you read the entire interview, because Alan Kay was, in fact, criticizing people with just your views. About C++, he also said "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind".

As it happens, I read the following article by Poul-Henning Kamp just the other day and had mixed feelings.

HTTP/2.0 — The IETF is Phoning It In (January 2016)

Mikko, what's your take on HTTP/2.0 in light of PHK's declared position?

—

For context, here are the two points that raised my own eyebrows.

First, PHK implies that HTTP/2.0 could have done something substantial to address the cookie problem.

This is almost triply ironic, because the major drags on HTTP are the cookies, which are such a major privacy problem, that the EU has legislated a notice requirement for them. HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier. That would put users squarely in charge of when they want to be tracked and when they don't want to—a major improvement in privacy.

The reason HTTP/2.0 does not improve privacy is that the big corporate backers have built their business model on top of the lack of privacy. They are very upset about NSA spying on just about everybody in the entire world, but they do not want to do anything that prevents them from doing the same thing.

Second, PHK implies that encryption is enough of a burden in certain circumstances to make exceptions to the privacy by default revolution. My own gut instinct is that SSL is already cheap enough to simply write off across the board as the cost of doing business, almost always.

Local governments have no desire to spend resources negotiating SSL/TLS with every single smartphone in their area when things explode, rivers flood, or people are poisoned. ... Yet, despite this, HTTP/2.0 will be SSL/TLS only, in at least three out of four of the major browsers, in order to force a particular political agenda.

Isn't it a rather crappy security profile to leave your "innocent" activities in clear text and only encrypt what is conventionally considered "sensitive"?

I did read a valid complaint the other day, where people writing servers trying to maintain 100,000 persistent SSL connections (average connection time measured in hours) become hot and bothered about the 20 kB per connection memory cost, enough to throw away a Go implementation (heavier in memory overhead) and go back to Ruby.

What say you about the technical/political HTTP/2 tango?

The research mentioned in the OP does not mention anything beyond capturing the RSA or ElGamal keys. However, in normal use, these keys are used to create "session keys" (also known as "message keys"). From http://www.pgpi.org/doc/pgpint... (PGP is the forerunner of GPG, which was designed to inter-operate with PGP)

PGP then creates a session key, which is a one-time-only secret key. This key is a random number generated from the random movements of your mouse and the keystrokes you type. This session key works with a very secure, fast conventional encryption algorithm to encrypt the plaintext; the result is ciphertext. Once the data is encrypted, the session key is then encrypted to the recipient's public key. This public key-encrypted session key is transmitted along with the ciphertext to the recipient.

From the same page

A digital certificate consists of three things: A public key. Certificate information. ("Identity" information about the user, such as name, user ID, and so on.) One or more digital signatures.

Also, the page describes PGP Certificates as including

The certificate holder's public key — the public portion of your key pair, together with the algorithm of the key: RSA, DH (Diffie-Hellman), or DSA (Digital Signature Algorithm).

There is no description of a procedure for deriving any kind of intermediate key from the public key in the certificate.

So, the 4096 bit keys discussed in the OP might be the public keys contained in the certificates. In which case, these 4096 bit keys might be in use for months or years.

I hope there actually are intermediate keys being generated. If not, a disruptive redesign of the encryption tools we use will be needed. However, any existing encrypted files would still be subject to the analysis by the described attacks, so the "blinding" mentioned in the research would still be needed. Also, it does not mention anything about changes to how the keys are actually used.

Also, the OP (and headline) fails to mention that the research also discusses other methods, including a person, with a concealed device, merely resting their hand on the computer for a few seconds. I suspect this infers that blinding the analysis is even more important.

Well there's the thing! Even with FOSS, most people do not compile their own binaries, and there's the trust issue again. And if your compiler is backdoored the same way as the package maintainer's compiler (which is perfectly possible if you both got your compilers from the same place), both will generate the same altered output. That is to say, the package maintainer may not even be the malicious party.

Check out Ken Thompson's Reflections on Trusting Trust. Yes, it's old, probably older than you if you haven't read it already, but it's still relevant, and will remain so for as long as we use computers.

Sure, you can review the source and fix security flaws that you find there; but, how can you know your compiler isn't replacing them or adding others? Read the paper.

... if you build everything yourself, starting with the toolchain. Of course, the first part of that is the firmware that starts the system, followed by the bootloader called by the firmware.

I gave an explanation of what should be a self-evident fact. Something that is self-evident it, in fact, evidence of itself and, therefore, requires no additional evidence. That being said, Ken Thompson's Reflections on Trusting Trust explains it a bit better than I could. Mind you, it's been well over a decade and a half since I've read it, but the concepts he discusses there still ring true, and wi continue to dk so for as long as we continue to use computers.

stupid laws that do not protect anyone from anything

Of course, they do protect — encryption is a weapon and you try to limit access to your best stuff. Yes, the enemies may still be able to get some of it, but your efforts make it harder for them.

Cryptography advances outside of the US made the point moot by early nineties, and the export-restrictions were dropped. But they weren't "stupid" — except, maybe, for the very last year or two.

The article's emphasis is all wrong — the vulnerabilities are due to poor design of SSL2 and the coding practices of OpenSSL developers leading to poor implementation of the rest. Neither of these problems is due to the government's export-restrictions.

Wonder if the Computer Science Teachers Association will modify their just-released proposed standards, which suggests teaching kids that tech has eliminated the need to worry about one's Uber Driver. From the 2016 CSTA K-12 CS Standards: "Compare the positive and negative impacts of computing on behavior and culture (e.g., Evolution to Uber: in 1970s OK to hitch-hike; 1980s dangerous to hitch-hike; 2015 OK to share ride with person met few minutes ago on app; airbnb - worldwide accommodation searches in homes, apts., etc.),"

Correlation is not causation.

I did not imply that it is, I said that it disproves your assertion. If you make an assertion that $X causes $Y, and we find an inverse correlation, then we can be pretty sure that $X does not cause $Y. You asserted that $ISM causes $OBSERVATION. I contend that assertion by observing that $ISM is actually inversely correlated to your $OBSERVATION.

And I doubt the correlation. Do you have any evidence to support your conclusion, like a peer reviewed study?

You would doubt it; your ideology fails if the correlation of "more options for girls" = "Less girls in CS". Let's look at my observations, shall we?

Iran (few female rights): females account for 70% CS and STEM graduates (source)

Gulf region (so few female rights they can't even display their face in linked photo): females account for 60% CS and STEM graduates (source)

Qatar (few female rights): females account for 60% of CS and STEM students (source)

Malaysia (few rights for women): females account for 52% of CS undergraduates (Peer reviewed source)

Now let's see what the top ten feminist countries in the world look like:

Finland: 32% female CS students (source)

Sweden (possibly the largest number of female rights in the world?): 22% CS grads (source

Norway - newest figure I can find on line is from 1999, so ignoring it for now

New Zealand: less than 33% female CS graduates (source).

UK: 13% female CS graduates (source)

Canada: 27% female graduates (maths and CS) (source)

USA: 18% female graduates in CS (source

Netherlands: Can't find sources for this either.

The best countries for female rights have fewer female CS graduates than the worst countries for female rights. This is directly observable.

Now that I got some of the numbers, you just know that I'm going to repost this list (not a link, the actual list) every time you make the incorrect assertion that sexism *must* be responsible for the dearth of females in CS.

My position is backed by evidence. Women's experiences, detailed and comprehensive studies. I'm on my phone now so ask again tomorrow if you want a list, but Wikipedia has a good article about it with 59 references: https://en.m.wikipedia.org/wik...

You've given a list of 59 references, of which only one academic article supports your position (somewhat tenously, but there you go). As it is clear that you did not read your own references, I'll leave it to you to figure out which one supports your $X causes $Y position. The other articles all repeat your mantra - that there are fewer females in CS - but none of them address the glaring issue of why this is not

The first amendment does apply to the publishing of encryption algorithms, as has been ruled by the Ninth Circuit in Bernstein v. United States and upheld in Junger v. Daley by the Sixth Circuit.

If you think these politicians can't destroy cryptography though, think again. They can, and will if you don't fight back and defend your rights. A good read that was published in acmqueue is "More Encryption Is Not the Solution", which outlines some of the practical issues involved, and why winning this political fight is very important.

You can look sat thereasoning in the 1999 article Why Johnny can't encrypt: a usability evaluation of PGP 5.0. It's quite sad how little progress we have seen in 16 years.

Ada and Java apparently

http://dl.acm.org/citation.cfm...

It's the same in computer science. Many measurement methodologies are plain wrong or misleading. And in many cases, the source code of what people did is not available, so independent evaluation is not possible (someone also published a paper about that, where the author couldn't even get the code in many cases after explicitly asking for it, but I forgot the title). It's not just a problem of alpha sciences.

So, "its work to continue," is a misnomer then. It's more accurate to state that other organizations with similar objectives will continue to pursue them even though this organization has bowed-out. It's not like the closing of this organization is directly causing its resources and specific pursuits to be applied post-mortem.

You're correct: their donors and volunteers and supporters won't automatically transfer to another organization, and that this the most unfortunate part of the Ada Initiative shutting down. Hence, I feel compelled to suggest other, like-minded organizations. My personal favorite "best match" is the Anita Borg Institute, but ACM-W or SWE run close seconds (in my mind at least). Indeed, I met "Val Henson", and still have trouble remembering her name change to "Valarie Anita Aurora".... perhaps Val can chime in herself about which charity she would prefer people support, but I'd put money on ABI.

You are thinking like a manager.
As a programmer, I don't want to be replaced easily, and I don't care about my work when I'll die, or even when I quit my company.
I have no problem to share my knowledge with my co-workers, but why should I write code for somebody who'll replace me ?

Software Engineer Code of Ethics

Your own insecurities related to job security are compromising your ethical values.

When a system you build fails or costs more to maintain than it really should all because you are scared of losing a job, you are not providing the value to your project or society that the profession demands and reflects negatively on everyone here. Don't ever call yourself a professional, don't comment on the matter, and quite frankly, get the hell out.

Well, he also published a paper with similar content in 2011 (while working at Microsoft Research).

Still, not news

Maybe Tony Abbott had to learn APL, and failed abysmally (not knowing that APL is easy). It might explain his anathema for all things digital.

Some of us actually liked APL... The art of obfuscation in at most one line!

1. Article in Communications of the ACM
2. Video I made about it

These are well-established, well-tested, well-designed protocols with no suspect commercial interests involved. QUIC solves nothing that hasn't already been solved.

Yeah, but it's from Google, and whatever Google wants, Google gets. They've already done this with SPDY, rammed through the IETF with unseemly haste as "HTTP 2.0", with any objections either ignored or declared out of scope. I don't see how QUIC will be any different, the IETF will rename it to give the impression they had some input into the process, but that'll be all.

A very simple Google search for swarm and robot will pop a horde of papers. Frankly, I've seen this research go back more than fifteen years. I'm too lazy to find the oldest source, but here's a bunch of different swarm papers:

http://link.springer.com/artic...

http://link.springer.com/chapt...

http://link.springer.com/artic...

https://dl.acm.org/citation.cf...

Sometimes you can find things under the term cooperative control. There's entire books written about these algorithms:

https://books.google.com/books...

So, yes, the Navy's system is cool. It is not revolutionary. It's an application of existing methodology.

There is no "now" [1]. If you're relying on accurate timing from a network, you're already broken. If you require accurate local times, then you know that and know the error terms on your clocks. Standard OS clocks only tick at about 100hz, so you're always out by an average of 5ms anyways.

[1] https://queue.acm.org/detail.c...

The two aren't even the same skillset. I've known plenty of security experts who could rattle off the math behind a prng or the algorithm for a secure cryptographic hashing function or how to correctly use java.security, but who couldn't write shippable code to save their life. I've also known plenty of developers who could build a great mobile game in a few hours or an efficient and realistic crowd simulator or a massively scalable data layer, but don't know the first thing about security. I know very, very few people who are both security experts AND badass devs, and they are mostly either superstar academics or principal engineers at the tech giants.

I disagree that not knowing both makes them bad devs, as security is just one specialization in many. As long as a dev can build quality software and either has a working knowledge of a lot of aspects of software engineering or is an expert in one or two areas, they are a good dev in my book. What IS worrying is that a lot of people who seem to think they are security experts clearly aren't. Papers like this one point to the need for more devs to specialize in security, which is a totally different issue than the one OP brings up: http://dl.acm.org/citation.cfm...