You've written a cogent and interesting post, and I'm also a fan of declarative programming, but I think you're just wrong about what is easier for people. It appears to me that declarative programming is much harder for people to learn than procedural programming. I think you're arguing that this is because that's what we teach people first, but I think it goes deeper than that, that non-procedural paradigms are inherently much harder for people to get their heads around. In particular, repetition and selection are much more naturally expressed in procedural forms. Go explain recursively processing a list to your grandmother.
That said, I think that once you understand declarative programming, it's more elegant and less error-prone. Though harder to debug when it goes wrong.
The "programming" (i.e. scheduling and process planning),of past centuries was declarative, not imperative
I also disagree with this. Scheduling and process planning is generally thought through and documented in sequential, imperative ways. Organizational structure is more declarative in nature, but I think people have a harder time understanding organizational structures and their implications than they do plans.
Not being able to plan would prohibit being able to structure a program.
I see program structure as a collection of abstract components with particular relationships between them, not as a long sequence of steps. In procedural programming languages, individual building blocks are plan-like in that they lay out a particular sequence of steps to accomplish a specific purpose, but even there the content of a function is quite different from a plan, at least to my way of seeing it. In functional languages, programs have almost nothing at all plan-like in them.
There is also some amount of forward looking analysis needed to be a good programmer, but it's more recognition of characteristics of good and bad architectures, designs and code -- some properties lead to long-term flexibility and maintainability while others lead to future trouble. But that's also not an endeavor that looks anything at all like planning.
The AC's comments about the fundamental differences between code, which is fixed during implementation and executed slavishly during execution, and a plan, which is less detailed, ad-hoc, not fixed during planning and refined during execution are also relevant. Programming and planning have almost nothing in common.
You could also see that if you broke the TLS encryption.
If Google wanted to smuggle data about kids back to their servers, they could do that steganographically, in DNS queries or images or battery usage reports. Since Google seems to be using a lot of deep learning for data mining, the data you are looking for would also be just a bunch of floating point numbers, data that may not even be decodeable using any information on the device.
Steganographically-embedded data is a little bit difficult, but most protocols don't have much room for embedding information from the client. You can do it in DNS, but only by adding unusual extensions to your queries. Form posts are a good one, since you have a fair number of bits to play with in the boundary strings. You could do a little bit with TLS key agreement negotiations. But still, these are pretty narrow channels. As for data that isn't decodeable, the presence of undecodeable data would be cause for concern... if it were present.
My point is that you can demonstrate the presence of data leakage, but you can't conclusively prove its absence to people who start with the assumption that Google is dishonest and adversarial.
No, but you can convince people who hold more moderate positions.
It's harder to prove that Google doesn't sync plaintext in addition to (or instead of) the encrypted content.
I doubt they'd do anything so blatant; they'd more likely just do data mining on the client and then send the mining results back to the server.
You could also see that if you broke the TLS encryption. And would get almost as famous. I'm tempted to do it and publish my findings, but there's no point because (a) I'm quite certain I wouldn't find anything hinky and (b) since I work for Google no one would believe a negative result. I'd like to see someone not associated with Google do this: breaking into TLS on a Chromebook and monitoring everything that gets sent to Google and comparing it with Google's public statements about privacy.
Hmm. https://jimshaver.net/2015/02/... indicates that there may actually be a really easy way to decrypt TLS traffic from Chrome. It's not clear how difficult the key logging would be to set up on ChromeOS. I'm going to ask some of my ChromeOS buddies. Maybe, if it's easy enough, I will do this myself. No one will believe my results but I can document the methodology for them to replicate.
(Aside: I've been toying with the idea of building a "dump all traffic, unencrypted" tool into Android, specifically to make it easy for people to verify exactly what Android devices do and do not send to Google -- and other parties. I'm not sure it can be done in a way that ensures that only the user can do it, though, and making such a built-in tool available to attackers would be a Bad Thing.)
If you don't trust Google how does that help? They still control the browser, the OS, and the encryption. And they still store all the files.
Well, the sync password encryption algorithm is in Chromium, so you can see exactly how it works. It's harder to prove that Google doesn't sync plaintext in addition to (or instead of) the encrypted content. That would require breaking the TLS connection security -- which is possible on a dev mode Chromebook, you just need to extract the ephemeral key pair from the browser, use that to decrypt the TLS stream, then verify that only the encrypted data is synced and that it's encrypted the same way as in the open source browser.
It would be a bit of work. If you did it and proved that Google was sending unencrypted data even though you'd set a sync password, though, you'd be famous.
At $5, a Pi Zero also becomes an alternative to an Arduino in cases where you could use a more powerful system running a real OS. I'm working on a custom home automation system, and I'm revising my design to replace a number of arduinos with Pi Zeros.
Of course, that's not an education application, which is what they're nominally aimed at. But, still, they're tiny, cheap and (relatively) powerful. What's not to like?
Is there any evidence that Google *doesn't* mine the synced data?
What sort of evidence would you accept? Note that the consent decree Google signed with the FTC requires that Google submit to regular privacy audits. But I'm guessing that doesn't reassure you, so I'm curious as to what would.
(Note: I work for Google so I'm not commenting on the EFF's allegations and won't respond to any discussion that gets close to them.)
Google Player Services, aka Google's spyware* gets a free ride and its spyware can't be turned off. This service tracks location and even if you disable all Google services they continue to get the information.
Cite? You absolutely can disable permissions for Google Play services, and my team (Android security) would consider it a severe bug if Play services could work around those permission blocks.
That is just the tip of the iceberg as to what that tracks.
Again, cite?
Other similar features in other Android distributions, return empty data to the app, so it might demand access to the camera, but the camera data it gets is a noise image, and it might demand your address book, but it gets an empty address book instead if you refuse it access. So the app cannot know it has been refused access to the data and cannot leverage that to force you to give it access.
Sure it can. Lying to apps would just create an arms race between the OS's attempts to hide the fact that users had blocked some permission and the app's attempts to determine it. That's not an issue with other distributions because the numbers are so small that apps don't bother. Better just to be up front to apps about the fact that they've been refused, plus do the other things the Play store already does to identify and minimize abusive apps.
BTW, another issue with permission denial is that it's not always obvious to users why an app needs a particular permission, even though it is totally legitimate and the user would absolutely want to allow that permission if they understood the reason. So 6.0 not only lets an app know that the user refused, but offers the app an opportunity to ask for the permission again, and the second time to offer an explanation as to why the permission is needed. If the user says no even with the explanation, the app doesn't get another shot. (This is my understanding, based on the presentations and demos I've seen. I haven't tested it myself.)
so much for open standards and open source software... 'its safe. you can look at the code yourself"... it took two and a half fucking years for someone to do just that.. and just to find an easter egg, not an embedded and obscured vulnerability.
No, it didn't take 2.5 years to get noticed. Look at the comments on the final commit, it was noticed and commented on by another team member the same day it went in. https://github.com/http2/http2...
The public didn't notice, but I'm sure many people involved in the project did... the commit wasn't in any way obscured. It just wasn't interesting enough for anyone else to notice.
NSLs are restricted to allowing collection only of "non-content information", or metadata. But what does that mean? In the case of telephone calls, it's pretty clear. With web history, though, it's much less clear, because a list of URLs is a list not only of which servers you connected to, but in most cases also what information you retrieved. The URL doesn't contain the information itself, but it's trivial for someone else to retrieve it and find out what you read.
Cell location information is another debatable case. While in some sense it is metadata if we consider the content to be what you talk about on the phone, the data you send/receive, etc., it's also tantamount to having a tracking device on almost everyone. Courts have ruled that GPS tracking without a warrant is unconstitutional, and it really seems that this is the same thing. The precision is lower, but it's still pretty darned good.
As for purchases, it would seem that information about what you bought and how much you paid for it would constitute "content", while the times and locations of the transactions would be metadata.
IP addresses of people you corresponded with... that seems like pure metadata, and is unsurprising to me.
No, it wasn't a war. It was a series of heavy-handed, ultra-violent overreactions to minor incidents which themselves were responses to systematic oppression. Military action often does kill civilians, the so-called "collateral damage", but herding groups of unarmed women and children into a building and then deliberately shelling that building to kill them all is not collateral damage; the unarmed civilians were the target.
If you want to understand what's really going on in Israel, I highly recommend you read "Goliath: Life and Loathing in Greater Israel", by Max Blumenthal. It's a hard book to read, not because Blumenthal isn't a good writer but because the truth is so horrible. And if you doubt that it is the truth, check the included citations.
What you seem to be missing is that War is a macro-aggressive, acute failure of society. Microaggression is a stealthy, sinister, chronic failure of society that is far more widespread and far more damaging to the long-term health of humanity than is an acute War that has a beginning and an end.
Others have addressed the first major flaw in this argument, which is that killing people is worse than being mean to them.
But there's another flaw, which is your apparent belief that microaggression is something new. It is definitely not. People have always been nasty to each other, and we're significantly less nasty to each other today than ever before. The notion of microaggression is perhaps the best proof: previous generations didn't even bother thinking about microaggression, because it was just normal. Today, we recognize this subtle form of personal attack and work to expose it and thereby reduce it.
You should read the first few chapters of Steven Pinker's "The Better Angels of Our Nature", in which he documents historical evidence of the ways in which people were nasty to each other. He focuses mostly on physical nastiness, violence, but lots of other sorts of nastiness are covered in passing, or obviously implied. Society is much, much better than it used to be. Empathy for strangers is normal today. It wasn't always.
In 1914, there was no entertainment as you imagine.
So radio, films, plays, books, and concerts didn't exist?
Note the correction of the year. 1940 was obviously a typo, the discussion was about 1914.
Radio was demonstrated but not used commercially in 1914. No, films didn't exist. Plays and concerts did, but high-quality productions were pretty much limited to major cities. Books, yes.
books were expensive and rare, etc.
Poppycock, etc.
I have difficulty believing anyone could be so completely ignorant of history. But apparently you are.
Compared to today, yes, books were expensive and rare. Most everything was dramatically more expensive than it is today, in terms of what a person with the median income could afford, and that included books. In 1914 most homes had a small number of books, far fewer than today. But the typical person also had far less leisure time.
If they are publicly traded and their principal business is not risk, then they are required to be by law.
Cite?
I'm fairly certain there is no such law. What publicly-traded businesses are required to do is to do what they say they'll do in their articles of incorporation and their prospectus. For most, these documents state that their focus is to generate a responsible return on investment (language varies, but that's what it boils down to). However, it is perfectly acceptable for them to include other goals, and even to prioritize those goals over making money.
Were SpaceX to go public, they could specify that their primary goal is to get to Mars, for example, rather than to make money. That would probably lower their valuation, but there would be nothing at all illegal about it.
The real question is not are engineers 9 times more likely to be terrorists. The real question is are they 9 times more likely to hold extremist beliefs, or just 9 times more likely to act on them because to engineers the point is to solve problems.
I suspect it's some of both. It seems to me that engineers do tend to be more passionate about their interests (whatever those may be) than the average person. And they think in terms of how to solve problems.
Does your smart TV have a microphone or camera? Some do, some don't? Who is the manufacturer if you don't mind me asking? Samsung seems to be the most gregarious about seizing "rights" in their TOS.
And in the meantime it is sending bog-knows-what to who-knows-what. I think I'll pass....
I didn't pass, I checked. I had my router log the packets from my TV for a couple of weeks, then fired up Wireshark to look at who it was talking to and what it was sending. Result? On a daily basis it sends a tiny request to the manufacturer, which I suspect is checking for firmware updates. Other than that, it appears to connect to Netflix when I watch Netflix, my DLNA server when I watch stuff from it, YouTube when I watch that, etc. That's it.
It also occurs to me... if you're worried about a information being sent who knows where, why are you not worried about your Roku, etc.? How do you know what it's sending? Why is a Smart TV riskier than any of the other network-connected media-playing devices you might hook to it?
Slashdot Mirror
You've written a cogent and interesting post, and I'm also a fan of declarative programming, but I think you're just wrong about what is easier for people. It appears to me that declarative programming is much harder for people to learn than procedural programming. I think you're arguing that this is because that's what we teach people first, but I think it goes deeper than that, that non-procedural paradigms are inherently much harder for people to get their heads around. In particular, repetition and selection are much more naturally expressed in procedural forms. Go explain recursively processing a list to your grandmother.
That said, I think that once you understand declarative programming, it's more elegant and less error-prone. Though harder to debug when it goes wrong.
The "programming" (i.e. scheduling and process planning),of past centuries was declarative, not imperative
I also disagree with this. Scheduling and process planning is generally thought through and documented in sequential, imperative ways. Organizational structure is more declarative in nature, but I think people have a harder time understanding organizational structures and their implications than they do plans.
didn't all of the com.sun packages change to com.oracle or something like that?
Yes, but you really shouldn't be using those packages anyway. They're non-standard, internal implementation details.
Not being able to plan would prohibit being able to structure a program.
I see program structure as a collection of abstract components with particular relationships between them, not as a long sequence of steps. In procedural programming languages, individual building blocks are plan-like in that they lay out a particular sequence of steps to accomplish a specific purpose, but even there the content of a function is quite different from a plan, at least to my way of seeing it. In functional languages, programs have almost nothing at all plan-like in them.
There is also some amount of forward looking analysis needed to be a good programmer, but it's more recognition of characteristics of good and bad architectures, designs and code -- some properties lead to long-term flexibility and maintainability while others lead to future trouble. But that's also not an endeavor that looks anything at all like planning.
The AC's comments about the fundamental differences between code, which is fixed during implementation and executed slavishly during execution, and a plan, which is less detailed, ad-hoc, not fixed during planning and refined during execution are also relevant. Programming and planning have almost nothing in common.
Planning is programming. In a way this reflects the post. Some people plan and prepare. They can program.
I'm lousy at planning, but a pretty decent programmer. I know lots of good programmers who are bad at planning.
If Google wanted to smuggle data about kids back to their servers, they could do that steganographically, in DNS queries or images or battery usage reports. Since Google seems to be using a lot of deep learning for data mining, the data you are looking for would also be just a bunch of floating point numbers, data that may not even be decodeable using any information on the device.
Steganographically-embedded data is a little bit difficult, but most protocols don't have much room for embedding information from the client. You can do it in DNS, but only by adding unusual extensions to your queries. Form posts are a good one, since you have a fair number of bits to play with in the boundary strings. You could do a little bit with TLS key agreement negotiations. But still, these are pretty narrow channels. As for data that isn't decodeable, the presence of undecodeable data would be cause for concern... if it were present.
My point is that you can demonstrate the presence of data leakage, but you can't conclusively prove its absence to people who start with the assumption that Google is dishonest and adversarial.
No, but you can convince people who hold more moderate positions.
I doubt they'd do anything so blatant; they'd more likely just do data mining on the client and then send the mining results back to the server.
You could also see that if you broke the TLS encryption. And would get almost as famous. I'm tempted to do it and publish my findings, but there's no point because (a) I'm quite certain I wouldn't find anything hinky and (b) since I work for Google no one would believe a negative result. I'd like to see someone not associated with Google do this: breaking into TLS on a Chromebook and monitoring everything that gets sent to Google and comparing it with Google's public statements about privacy.
Hmm. https://jimshaver.net/2015/02/... indicates that there may actually be a really easy way to decrypt TLS traffic from Chrome. It's not clear how difficult the key logging would be to set up on ChromeOS. I'm going to ask some of my ChromeOS buddies. Maybe, if it's easy enough, I will do this myself. No one will believe my results but I can document the methodology for them to replicate.
(Aside: I've been toying with the idea of building a "dump all traffic, unencrypted" tool into Android, specifically to make it easy for people to verify exactly what Android devices do and do not send to Google -- and other parties. I'm not sure it can be done in a way that ensures that only the user can do it, though, and making such a built-in tool available to attackers would be a Bad Thing.)
that"real" os is not realtime. the bare avr is.
Meh. Few home automation tasks, if any, care. Basically nothing that operates on human timescales does.
If you don't trust Google how does that help? They still control the browser, the OS, and the encryption. And they still store all the files.
Well, the sync password encryption algorithm is in Chromium, so you can see exactly how it works. It's harder to prove that Google doesn't sync plaintext in addition to (or instead of) the encrypted content. That would require breaking the TLS connection security -- which is possible on a dev mode Chromebook, you just need to extract the ephemeral key pair from the browser, use that to decrypt the TLS stream, then verify that only the encrypted data is synced and that it's encrypted the same way as in the open source browser.
It would be a bit of work. If you did it and proved that Google was sending unencrypted data even though you'd set a sync password, though, you'd be famous.
How about if you had a private key used to encrypt the data before it was synced?
Google actually provides that. You can set a sync password which is used to derive a key that is used to encrypt the data before it's synced.
At $5, a Pi Zero also becomes an alternative to an Arduino in cases where you could use a more powerful system running a real OS. I'm working on a custom home automation system, and I'm revising my design to replace a number of arduinos with Pi Zeros.
Of course, that's not an education application, which is what they're nominally aimed at. But, still, they're tiny, cheap and (relatively) powerful. What's not to like?
Is there any evidence that Google *doesn't* mine the synced data?
What sort of evidence would you accept? Note that the consent decree Google signed with the FTC requires that Google submit to regular privacy audits. But I'm guessing that doesn't reassure you, so I'm curious as to what would.
(Note: I work for Google so I'm not commenting on the EFF's allegations and won't respond to any discussion that gets close to them.)
Google Player Services, aka Google's spyware* gets a free ride and its spyware can't be turned off. This service tracks location and even if you disable all Google services they continue to get the information.
Cite? You absolutely can disable permissions for Google Play services, and my team (Android security) would consider it a severe bug if Play services could work around those permission blocks.
That is just the tip of the iceberg as to what that tracks.
Again, cite?
Other similar features in other Android distributions, return empty data to the app, so it might demand access to the camera, but the camera data it gets is a noise image, and it might demand your address book, but it gets an empty address book instead if you refuse it access. So the app cannot know it has been refused access to the data and cannot leverage that to force you to give it access.
Sure it can. Lying to apps would just create an arms race between the OS's attempts to hide the fact that users had blocked some permission and the app's attempts to determine it. That's not an issue with other distributions because the numbers are so small that apps don't bother. Better just to be up front to apps about the fact that they've been refused, plus do the other things the Play store already does to identify and minimize abusive apps.
BTW, another issue with permission denial is that it's not always obvious to users why an app needs a particular permission, even though it is totally legitimate and the user would absolutely want to allow that permission if they understood the reason. So 6.0 not only lets an app know that the user refused, but offers the app an opportunity to ask for the permission again, and the second time to offer an explanation as to why the permission is needed. If the user says no even with the explanation, the app doesn't get another shot. (This is my understanding, based on the presentations and demos I've seen. I haven't tested it myself.)
Do you have any idea how incredibly valuable "metadata" is for signals intelligence?
Yes. What's your point?
for this to get "noticed"?
so much for open standards and open source software... 'its safe. you can look at the code yourself"... it took two and a half fucking years for someone to do just that.. and just to find an easter egg, not an embedded and obscured vulnerability.
No, it didn't take 2.5 years to get noticed. Look at the comments on the final commit, it was noticed and commented on by another team member the same day it went in. https://github.com/http2/http2...
The public didn't notice, but I'm sure many people involved in the project did... the commit wasn't in any way obscured. It just wasn't interesting enough for anyone else to notice.
NSLs are restricted to allowing collection only of "non-content information", or metadata. But what does that mean? In the case of telephone calls, it's pretty clear. With web history, though, it's much less clear, because a list of URLs is a list not only of which servers you connected to, but in most cases also what information you retrieved. The URL doesn't contain the information itself, but it's trivial for someone else to retrieve it and find out what you read.
Cell location information is another debatable case. While in some sense it is metadata if we consider the content to be what you talk about on the phone, the data you send/receive, etc., it's also tantamount to having a tracking device on almost everyone. Courts have ruled that GPS tracking without a warrant is unconstitutional, and it really seems that this is the same thing. The precision is lower, but it's still pretty darned good.
As for purchases, it would seem that information about what you bought and how much you paid for it would constitute "content", while the times and locations of the transactions would be metadata.
IP addresses of people you corresponded with... that seems like pure metadata, and is unsurprising to me.
It was a war. Shit happens.
No, it wasn't a war. It was a series of heavy-handed, ultra-violent overreactions to minor incidents which themselves were responses to systematic oppression. Military action often does kill civilians, the so-called "collateral damage", but herding groups of unarmed women and children into a building and then deliberately shelling that building to kill them all is not collateral damage; the unarmed civilians were the target.
If you want to understand what's really going on in Israel, I highly recommend you read "Goliath: Life and Loathing in Greater Israel", by Max Blumenthal. It's a hard book to read, not because Blumenthal isn't a good writer but because the truth is so horrible. And if you doubt that it is the truth, check the included citations.
This anonymous is certainly smart and is most definitely not a retard. Keep going you not-a-retard.
That's a comeback worthy of Stuart Bloom.
What you seem to be missing is that War is a macro-aggressive, acute failure of society. Microaggression is a stealthy, sinister, chronic failure of society that is far more widespread and far more damaging to the long-term health of humanity than is an acute War that has a beginning and an end.
Others have addressed the first major flaw in this argument, which is that killing people is worse than being mean to them.
But there's another flaw, which is your apparent belief that microaggression is something new. It is definitely not. People have always been nasty to each other, and we're significantly less nasty to each other today than ever before. The notion of microaggression is perhaps the best proof: previous generations didn't even bother thinking about microaggression, because it was just normal. Today, we recognize this subtle form of personal attack and work to expose it and thereby reduce it.
You should read the first few chapters of Steven Pinker's "The Better Angels of Our Nature", in which he documents historical evidence of the ways in which people were nasty to each other. He focuses mostly on physical nastiness, violence, but lots of other sorts of nastiness are covered in passing, or obviously implied. Society is much, much better than it used to be. Empathy for strangers is normal today. It wasn't always.
In 1914, there was no entertainment as you imagine.
So radio, films, plays, books, and concerts didn't exist?
Note the correction of the year. 1940 was obviously a typo, the discussion was about 1914.
Radio was demonstrated but not used commercially in 1914. No, films didn't exist. Plays and concerts did, but high-quality productions were pretty much limited to major cities. Books, yes.
books were expensive and rare, etc.
Poppycock, etc.
I have difficulty believing anyone could be so completely ignorant of history. But apparently you are.
Compared to today, yes, books were expensive and rare. Most everything was dramatically more expensive than it is today, in terms of what a person with the median income could afford, and that included books. In 1914 most homes had a small number of books, far fewer than today. But the typical person also had far less leisure time.
If they are publicly traded and their principal business is not risk, then they are required to be by law.
Cite?
I'm fairly certain there is no such law. What publicly-traded businesses are required to do is to do what they say they'll do in their articles of incorporation and their prospectus. For most, these documents state that their focus is to generate a responsible return on investment (language varies, but that's what it boils down to). However, it is perfectly acceptable for them to include other goals, and even to prioritize those goals over making money.
Were SpaceX to go public, they could specify that their primary goal is to get to Mars, for example, rather than to make money. That would probably lower their valuation, but there would be nothing at all illegal about it.
Well, I'm an engineer and I work with engineers all day. I find the majority to be fairly liberal and not very religious.
Did you obtain a similar sample of people with other degrees to compare against?
The real question is not are engineers 9 times more likely to be terrorists. The real question is are they 9 times more likely to hold extremist beliefs, or just 9 times more likely to act on them because to engineers the point is to solve problems.
I suspect it's some of both. It seems to me that engineers do tend to be more passionate about their interests (whatever those may be) than the average person. And they think in terms of how to solve problems.
So I'm confused about this idea that engineers are more likely to be religious than the public at large. That just doesn't make sense to me.
The summary didn't say that. It said engineers are more likely to be religious than people with social science degrees.
Does your smart TV have a microphone or camera? Some do, some don't? Who is the manufacturer if you don't mind me asking? Samsung seems to be the most gregarious about seizing "rights" in their TOS.
No camera or microphone. It's made by Sharp.
And in the meantime it is sending bog-knows-what to who-knows-what. I think I'll pass....
I didn't pass, I checked. I had my router log the packets from my TV for a couple of weeks, then fired up Wireshark to look at who it was talking to and what it was sending. Result? On a daily basis it sends a tiny request to the manufacturer, which I suspect is checking for firmware updates. Other than that, it appears to connect to Netflix when I watch Netflix, my DLNA server when I watch stuff from it, YouTube when I watch that, etc. That's it.
It also occurs to me... if you're worried about a information being sent who knows where, why are you not worried about your Roku, etc.? How do you know what it's sending? Why is a Smart TV riskier than any of the other network-connected media-playing devices you might hook to it?