You can measure the quality of any streaming music service by typing the word "motown" into the search box.
Does Motown immediately start playing? A+
Is there a list of Motown playlists? A
Does something else happen? Fail.
I guess by your test, Google Music All Access gets an A, though personally I think what it does is better than immediately playing motown. What it provides is several sections: Motown artists, Motown albums, Motown songs, Motown Radio stations (similar to Spotify), Motown Playlists (apparently put together by users and shared to the world) and Motown videos, each with a selection of a half-dozen choices and a "See All" button that takes you to the rest of the matches for that section.
Not caring for Motown myself, I can't comment on the quality of the contents of the sections. It all looked pretty reasonable, though.
Relative to the points in the summary, Google also has Adele and Taylor Swift. Beatles... not so much. There are a bunch of "albums" but most of them are interviews along with a couple of albums including somewhat random songs... but none of their actual album releases. It's also possible that a couple of the music albums I see are not in the library, but were uploaded by me (you can upload your own music and it appears in the streaming service just as though it were part of the library. I think Metallica is also not in the library. I've uploaded all of their albums, so they're all there for me. It's possible I also uploaded some Adele, though there are albums I don't have so they must be from the library. And I don't own any Taylor Swift, so I'm sure all of that is from the library.
Oh, and Google Music's subscription also includes YouTube MusicKey, so whatever isn't available in the streaming service is almost certainly available there. The Beatles' music is, though not under a music license, so it's not available for download or background play.
(Disclosure: I work for Google, though I'm speaking here as a satisfied customer of the music service.)
The world without web search, or even the pre-search model of curated indexes (Yahoo!, also based on targeted advertising, though of a less effective form)? You're either trolling, or stupid.
Really? Keep in mind that without it Google search wouldn't exist... and neither would DDG, because most of DDG's sources are other engines that are also funded by advertising. Odds are that without Google's business model you'd also be seeing a lot more, and a lot more intrusive ads. You are probably too young to remember what the commercial side of the web looked like in the mid to late 90s, but I'm sure you've seen the "one weird trick" sites with pages and pages to present a small amount of content buried in mountains of ads. That was pretty much where we were headed until targeted advertising came along.
FYI, Google doesn't sell user data to aggregators either, or to advertisers. You may know that, but I mention it because it's a common misunderstanding of Google's advertising business model.
It couldn't be that bad, or people on mobile networks would burn most of their month's data setting up a new device.
And if that data is flagged in such fashion as to not count against one's data cap?
Android doesn't send any particular different parameters during setup. There's really no way the carrier could even know the difference. And if the device could send something that meant "hey, doing setup, don't charge this" you know custom ROMs would arrange to send that *all* the time, or at least as often as they can get away with.
One idea I've been toying with is a framework-level network tap that allows you to divert a copy of every bit that your phone sends or receives, via network, Wifi, bluetooth, NFC or USB, for your perusal and examination. Since most apps use the framework APIs for SSL, it should be possible to snarf this data before it's encrypted, too.
Good luck. I captured all the traffic that a nexus 7 sends during initial setup, and it was immense. Numerous hosts, protocols, you name it. A few hundred megabytes total. Very hard to make heads or tails of (especially given the encrypted content).
It couldn't be that bad, or people on mobile networks would burn most of their month's data setting up a new device.
And the idea would be to get as much as possible out before it's encrypted. It would still be tough to analyze, but people would figure it out.
Maybe I'm not clever enough, but I can't think of any way that an NSL could be used to suppress stories. One could be used to demand information about who looked at stories, and Google wouldn't be able to tell anyone that the list of watchers was provided, but it couldn't be used to force the story offline.
Only stories about NSLs.
I don't even think it's true. The NSL gag order applies to the recipient of the NSL, not the whole world. So Google couldn't use this service to distribute information about NSLs sent to Google, but they couldn't do that anyway.
There's also the possibility that the government is issuing secret gag orders which aren't so limited, but we have no evidence of that.
having access to source code that purports to be what's running on the device doesn't get you there.
hence the superiority of the gentoo/lfs/etc approach:) but building Android is a serious nightmare... even if they wanted to give you the code.
No kidding. There's a reason my workstation has 40 cores and 128 GiB RAM.
I perceive untampered Android security as pretty good, though.
I do, too, actually. Far better than I thought it would be. It's refreshing to hear someone outside of Google say that, though:-)
As long as you need root elevation, it seems like the kind of thing that you can keep users from shooting themselves with accidentally. What more can you hope for?
Well, the current direction is to create a lot of firewalls between components that even root can't breach, using SELinux. This is obviously to reduce the impact of privilege escalation exploits, and even more important to eliminated many of them because many exploits today are actually exploit chains, so if SELinux can break any link, the whole exploit is DOA. We're actually seeing a lot of exploits for older versions which no longer work in L because SELinux is in enforcing mode.
If what I'm thinking about doesn't require poking any holes through SELinux firewalls, then it's a relatively minor risk, though it does make an attacker's job easier. Specifically, the sort of attack I'm most worried about in this context is what we call "spouse spying". It's obviously not restricted to spouses, but it's the sort of thing that non-trivial numbers of people want to do, and which is a real and occasionally dangerous problem (as in, people die from the fallout of such tools being readily available -- not that the tools are at fault, exactly, but we'd rather not facilitate it). So we're not in the abstract realm of "well, it's theoretically possible to...", this is about real-world attacks, and so merely making it harder actually does achieve something in many cases.
I may be unduly pessimistic about the dangers of such a "central I/O tap", because I haven't had time to look at it hard. I will, though. I fundamentally like the idea -- probably mostly because it was my idea:-) -- if I can convince myself (and my colleagues) that it doesn't create any unacceptable new risks.
Other ideas for creating greater transparency are welcome.
Hotword detection is optional in Android. If you don't like it, just turn it off.
The software which provides hotword detection on Android is also not auditable. How do you know it doesn't turn itself on when it detects that you're not looking at it, or monitoring it via adb? Oh no, I don't really think that it does either, but it's precisely the same concern as on Debian. You'd have to not install the google services to be sure you were avoiding it.
If that's your level of paranoia, you're lost, and omitting the Google services doesn't help.
The fact is that you implicitly and deeply trust all the companies in the production pipeline for the networked electronic devices you use, because absolutely any one of them can easily arrange for whatever sort of backdoor they want. It's a little tougher for the hardware component vendors, I'll grant, but if they do the work they're in the best position of all to compromise your security without any possibility that you could find it.
With Android specifically, though, I'm interested in ideas for how we can make the system more transparent. We can't do anything about hardware-level compromises, but I'd like it if the upper layers were more auditable -- and note that having access to source code that purports to be what's running on the device doesn't get you there.
One idea I've been toying with is a framework-level network tap that allows you to divert a copy of every bit that your phone sends or receives, via network, Wifi, bluetooth, NFC or USB, for your perusal and examination. Since most apps use the framework APIs for SSL, it should be possible to snarf this data before it's encrypted, too. Of course, there's a big downside: if this single data collection point exists, it will be a tremendously attractive target for compromise by other parties who want to see what your device sends or receives.
You're a smart person, do you have any ideas for what Android could do to make its operations more transparent? We can't achieve perfection, but if we could get it to the point where Google or anyone else in the supply chain would have to do something which is obviously and solely intended to hide their actions in order to exfiltrate private data, that would be great.
Note that this is not an idle question. I'm a member of the Android security team, and in a position to make these sorts of things happen, or at least dramatically increase the likelihood.
You only gave one example, and that one I found very quickly. I just searched for "elisp operators" and it was the second hit. Do you have better examples?
I look for all sorts of fairly obscure things and I really don't see the problem.
National Security Letters can't give arbitrary instructions to suppress information. The law defines NSLs quite precisely. They are a form of subpoena and therefore can only be used to request information, with the additional constraint that the recipient of the NSL cannot tell anyone that the NSL was received or the information was provided. In addition, NSLs can only be used to request metadata, not content.
Maybe I'm not clever enough, but I can't think of any way that an NSL could be used to suppress stories. One could be used to demand information about who looked at stories, and Google wouldn't be able to tell anyone that the list of watchers was provided, but it couldn't be used to force the story offline.
There's also the possibility that the government is issuing secret gag orders which aren't so limited, but we have no evidence of that.
unplug it, or if its embedded, remove the audio driver for it, or set the 'volume' control so it cannot hear anything anyway. And put some tape over the little hole it listens through.
Now.. good luck doing that on your phone.... best just to remove the app (if you can) or trust Google not to have slipped this stuff into Android as part of its voice activation feature (for your convenience, of course)
Hotword detection is optional in Android. If you don't like it, just turn it off.
Google, seriously, when are you going to fix this?
It is fixed.
Google spends a lot of effort on optimizing search and has very sophisticated and effective metrics for tracking what works well and what doesn't. The thing is that you don't search like 99.99% of people search, and so the feedback loop optimizes away from you and towards others. Another poster above mentioned that it's better when signed in... I don't know if that's actually true, but Google does do some degree of search personalization, so it makes sense.
I find actually get very good results from Google, but I've changed the way I search. 20 years ago I learned to create very precise queries, with + and - to force and trim queries, omitting conjunctions and other common words that I knew weren't indexed anyway, etc. I don't do that any more. What works better these days, I find, is just to type a plain English question. For example, I just pulled up my Google search history, and here are some of my searches from today. Notably, not a single one of my searches required going to the second page of results and nearly all of them gave me the answer I was looking for as the top link.
"convert camelcase to underscore-separated with emacs" -- Got me immediately to a stackoverflow post that told me about the string-inflection package, available on MELPA.
"Can I use a heat pump to balance temperature between rooms?" -- My home office (I work from home) is perpetually hotter than the rest of the house, so I wondered if I could put a heat pump through the wall. Turns out, probably not. I'll investigate a fan instead.
"octal format string for printf" -- I didn't recall %o. Duh.
"example code for sha256 with openssl" -- Got me exactly what I wanted.
"how effective are hate crime laws" -- They appear to have no measurable effect on the rate of hate crime commission, though they arguably send a positive social signal.
"how to break on memory write in gdb" -- "watch"
"how to set gcm nonce length with openssl evp api" -- What a nasty hack that is, but it does work.
"trim whitespace from variable in bash" -- use tr
"bash tee to two pipes" -- redirect to a subshell
"942-Memory Training Error" -- Ugh, I think one of the DIMMs in my workstation is bad. Tech support is shipping me a replacement.
I only had the one error message to search for, but that's typical of my strategy. I don't try to craft an ideal query, I just paste the whole damned thing and 99% of the time I get an answer. Or at least more people complaining about the same problem.
I think a lot of the complaints about the change in search engine is from people who are still trying to use modern search engines they way they used them in 2000. Don't. Don't carefully craft your queries, just type a question, or paste a big pile of related text. That's what the masses do, so that's what Google optimizes for.
(Disclaimer: I work for Google, but not on search and don't know much about how it actually works.)
This is the right basic idea, I think, but I think everything will converge into a single device, either the mobile phone or a wearable. And as it becomes more and more central to everything we do, that device will become very smart about authentication.
The problem with using dedicated embeddable devices is twofold. First, the more of them you have to carry, the more difficult it is to keep track of them. With old-fashioned metal keys we've solved this with the key ring... but that creates its own problem. The more keys you add to it, the more valuable it becomes. Loss or theft become increasingly more problematic. And our metal keys open fewer, and less important, things than our electronic authenticators do.
So, it makes sense to combine the electronic keys in a single device, but then to use the capabilities it has that metal keys do not to solve the theft and loss problems. First, against loss, there must be a way of backing up all of the credentials, securely and automatically, so that in the event the device is lost they can all be recovered relatively easily. Some sort of remote server backup, to which you authenticate with some other mechanism that you protect very carefully (there are lots of options here, but a long, randomly-generated password printed out and stored in a safe place is a good option). That backup needs to be reliable and reliably accessible, but access need not be easy or convenient, since it should be rarely needed.
What about theft? This is where the smart device has huge advantages over dumber devices, because it can authenticate the user. This authentication needn't be particularly strong, but it should have good anti brute-force protections, and it should be smart. The goal is to make something that is extremely convenient for the user, but makes it relatively unlikely that someone else who gets it can use it. How could that work? Google is pushing towards this vision with Android Smart Lock features. The core idea is that the device shouldn't rely on a single signal, because that signal then has to be very strong.
It's worth looking at analogies with meatspace facilities that care a great deal about security. What they don't do is put a bank vault door on the exterior wall and rely on the strong combination lock to keep thieves out. Instead, they rely on layering of defenses, monitoring and active response.
What can your phone do? Quite a bit, probably. Not only does it have a touchscreen for entering passwords, it also has cameras, an accelerometer, GPS, various radios, compass, altimeter, microphones, a proximity sensor and probably other stuff I'm forgetting. In addition, it can know a lot about your habits, your plans (e.g. what's on your calendar) and more. With that wealth of signals, it should be possible for the device to determine with relatively high certainty whether or not it is still in your possession. Where it's uncertain, it can fall back to asking for authentication with, say, a fingerprint or simple PIN to increase its certainty. Or in more extreme cases, it can fall back to an even stronger password. The idea is to make authentication as seamless, transparent and automatic as possible... but as strong as necessary.
Or maybe a smart watch will be a better choice. It has pretty much all the same capabilities as a phone, but the advantage that you strap it to your body, making it harder to lose, and harder to steal. (Actually, I think over the next few years for many of us our phones will migrate onto our wrists; right now the smart watch is an extension of the phone, I think that will flip, with the handheld device becoming an extension of the watch providing a larger screen, aimable camera, etc.).
The "as strong as necessary" bit is important here, too. When the phone is going to use a stored authentication key to unlock something for you, the degree of certainty that it needs to have that you're you depends on what it's unlocking. If I'm using my phone to log me into slashdot on my laptop, I really cou
"Even then #ifdefs are the wrong way to do it. Create a system abstraction layer (or use one of the several excellent ones that exist) and call that. Then for each platform build and link the appropriate implementation of the abstraction layer. "
Sorry, I disagree. Abstraction layers are inefficient and add to bloat especially if the code only differentiates in a few places between platforms. I'm sure they look nice on a whiteboard design but in the real world they're rarely the best solution for home grown code.
Bah. Well-designed abstraction layers have no significant overhead. I've designed and built many of them.
So, is it more lucrative to claim the bounty, or exploit the bug?
Seems to me you can sell it to shady people for more money.
Only if you're the sort to do that.
It's the norm across the whole industry that the black market in vulnerabilities is more lucrative than the "white hat" side. And yet, it appears that the white hat industry is far larger -- and probably more effective. Why? Multiple reasons: Most people want to be honest, many of them like the public recognition they get from publishing, and there are a lot of risks in dealing with the sorts of shady people who pay lots of money for vulnerabilities. The net is that the best people almost invariably end up either on the white hat side.
Bug bounties have proven to be highly effective. How does the industry know? Simple: monitor the prices of black market vulnerabilities. Vulnerability Reward Programs tend to cause a spike in black market prices far out of proportion with the VRP payments. Partly this is because VRPs tend to sweep up most of the low-hanging fruit quickly, and partly it's because given the choice between getting $8K and a public "thank you" from Google, plus being able to publish and present, is a lot more attractive to many people than getting $50K from the Chinese. Or the NSA.
Not if it does a lot of low level systems calls. Unless you think win32 is going to work on Linux for example or Xlib will have no problem working on Windows.
Even then #ifdefs are the wrong way to do it. Create a system abstraction layer (or use one of the several excellent ones that exist) and call that. Then for each platform build and link the appropriate implementation of the abstraction layer.
The C++ committee has been aggressively removing all need for the preprocessor. Function-style macros should be inline functions. Macro-based code generation should be replaced with templates. Constants should be actual constants. About the only valid need left is for header inclusion (including guards) and C++ modules will eliminate the need for both of those (assuming they arrive in C++17).
I doubt that C++ will ever be able to actually deprecate the C preprocessor, but we're moving towards not needing it any more.
Also, the US admitted it and then said they weren't doing it anymore. That's kind of odd - normally a public admission backed by documentary evidence would be sufficient for a criminal prosecution, no?
No the US never admitted it. The White House said it wasn't being done at present (in 2013) and wouldn't do it in the future, but refused to comment on whether it had been done in the past.
Also, it's not a crime for countries to spy on other countries. More precisely, there is no international law making it illegal. Countries have laws against spying, but German courts can't usefully prosecute the the United States. Germany could prosecute the specific people who installed the taps, assuming they could identify and get hold of them (the US obviously wouldn't honor an extradition request).
The whole notion of "crime" is simply irrelevant here. This is a question of international relations, where countries punish those they believe do them ill by other mechanisms, ranging from subtle snubs to nuclear war, with lots and lots of gradations in between.
As the Lavabit case demonstrated, any company that didn't cooperate would no longer exist, and the public wouldn't necessarily know why.
Nonsense.
You're conflating several issues. In fairness, this misunderstanding is common.
What happened in the Lavabit case was completely different. There were no NSLs or gag orders, the sequence of legal events is in the public record, and shutting down was Levison's own decision. What happened was that Levison not only refused to comply with narrowly-targeted orders for one particular individual's e-mail, but lied, saying that it was impossible for him to comply. His bad faith ultimately resulted in a court order to turn over the keys, because the FBI successfully argued that they couldn't trust him to provide the requested material, and so had to get everything. I think the court was wrong, but there's no reason to assume that a company that employs attorneys and fights orders in the court system, rather than trying to fool the court, would see any similar order.
Slashdot Mirror
You can measure the quality of any streaming music service by typing the word "motown" into the search box. Does Motown immediately start playing? A+ Is there a list of Motown playlists? A Does something else happen? Fail.
I guess by your test, Google Music All Access gets an A, though personally I think what it does is better than immediately playing motown. What it provides is several sections: Motown artists, Motown albums, Motown songs, Motown Radio stations (similar to Spotify), Motown Playlists (apparently put together by users and shared to the world) and Motown videos, each with a selection of a half-dozen choices and a "See All" button that takes you to the rest of the matches for that section.
Not caring for Motown myself, I can't comment on the quality of the contents of the sections. It all looked pretty reasonable, though.
Relative to the points in the summary, Google also has Adele and Taylor Swift. Beatles... not so much. There are a bunch of "albums" but most of them are interviews along with a couple of albums including somewhat random songs... but none of their actual album releases. It's also possible that a couple of the music albums I see are not in the library, but were uploaded by me (you can upload your own music and it appears in the streaming service just as though it were part of the library. I think Metallica is also not in the library. I've uploaded all of their albums, so they're all there for me. It's possible I also uploaded some Adele, though there are albums I don't have so they must be from the library. And I don't own any Taylor Swift, so I'm sure all of that is from the library.
Oh, and Google Music's subscription also includes YouTube MusicKey, so whatever isn't available in the streaming service is almost certainly available there. The Beatles' music is, though not under a music license, so it's not available for download or background play.
(Disclosure: I work for Google, though I'm speaking here as a satisfied customer of the music service.)
Boohoo. The world without google. THE HORROR!
The world without web search, or even the pre-search model of curated indexes (Yahoo!, also based on targeted advertising, though of a less effective form)? You're either trolling, or stupid.
Fuck google's business model.
Really? Keep in mind that without it Google search wouldn't exist... and neither would DDG, because most of DDG's sources are other engines that are also funded by advertising. Odds are that without Google's business model you'd also be seeing a lot more, and a lot more intrusive ads. You are probably too young to remember what the commercial side of the web looked like in the mid to late 90s, but I'm sure you've seen the "one weird trick" sites with pages and pages to present a small amount of content buried in mountains of ads. That was pretty much where we were headed until targeted advertising came along.
FYI, Google doesn't sell user data to aggregators either, or to advertisers. You may know that, but I mention it because it's a common misunderstanding of Google's advertising business model.
I may be unduly pessimistic about the dangers of such a "central I/O tap", because I haven't had time to look at it hard. I will, though.
So, how do you keep applications from knowing that the tap is in use? :)
That would be the easy part. There'd just be no way for them to tell.
It couldn't be that bad, or people on mobile networks would burn most of their month's data setting up a new device.
And if that data is flagged in such fashion as to not count against one's data cap?
Android doesn't send any particular different parameters during setup. There's really no way the carrier could even know the difference. And if the device could send something that meant "hey, doing setup, don't charge this" you know custom ROMs would arrange to send that *all* the time, or at least as often as they can get away with.
You are absolutely, positively 100% wrong.
Really? Care to support that claim?
Hunting through 10 links with none of the normal highlighting of terms is cumbersome.
Ctrl-F is your friend :-)
indexing every "/=" may not be super practical.
In that particular example, it's not even a change. None of the search engines have ever indexed much in the way of non-alphanumeric characters.
One idea I've been toying with is a framework-level network tap that allows you to divert a copy of every bit that your phone sends or receives, via network, Wifi, bluetooth, NFC or USB, for your perusal and examination. Since most apps use the framework APIs for SSL, it should be possible to snarf this data before it's encrypted, too.
Good luck. I captured all the traffic that a nexus 7 sends during initial setup, and it was immense. Numerous hosts, protocols, you name it. A few hundred megabytes total. Very hard to make heads or tails of (especially given the encrypted content).
It couldn't be that bad, or people on mobile networks would burn most of their month's data setting up a new device.
And the idea would be to get as much as possible out before it's encrypted. It would still be tough to analyze, but people would figure it out.
Maybe I'm not clever enough, but I can't think of any way that an NSL could be used to suppress stories. One could be used to demand information about who looked at stories, and Google wouldn't be able to tell anyone that the list of watchers was provided, but it couldn't be used to force the story offline.
Only stories about NSLs.
I don't even think it's true. The NSL gag order applies to the recipient of the NSL, not the whole world. So Google couldn't use this service to distribute information about NSLs sent to Google, but they couldn't do that anyway.
There's also the possibility that the government is issuing secret gag orders which aren't so limited, but we have no evidence of that.
There would be no point to it yet.
Fair enough.
having access to source code that purports to be what's running on the device doesn't get you there.
hence the superiority of the gentoo/lfs/etc approach :) but building Android is a serious nightmare... even if they wanted to give you the code.
No kidding. There's a reason my workstation has 40 cores and 128 GiB RAM.
I perceive untampered Android security as pretty good, though.
I do, too, actually. Far better than I thought it would be. It's refreshing to hear someone outside of Google say that, though :-)
As long as you need root elevation, it seems like the kind of thing that you can keep users from shooting themselves with accidentally. What more can you hope for?
Well, the current direction is to create a lot of firewalls between components that even root can't breach, using SELinux. This is obviously to reduce the impact of privilege escalation exploits, and even more important to eliminated many of them because many exploits today are actually exploit chains, so if SELinux can break any link, the whole exploit is DOA. We're actually seeing a lot of exploits for older versions which no longer work in L because SELinux is in enforcing mode.
If what I'm thinking about doesn't require poking any holes through SELinux firewalls, then it's a relatively minor risk, though it does make an attacker's job easier. Specifically, the sort of attack I'm most worried about in this context is what we call "spouse spying". It's obviously not restricted to spouses, but it's the sort of thing that non-trivial numbers of people want to do, and which is a real and occasionally dangerous problem (as in, people die from the fallout of such tools being readily available -- not that the tools are at fault, exactly, but we'd rather not facilitate it). So we're not in the abstract realm of "well, it's theoretically possible to...", this is about real-world attacks, and so merely making it harder actually does achieve something in many cases.
I may be unduly pessimistic about the dangers of such a "central I/O tap", because I haven't had time to look at it hard. I will, though. I fundamentally like the idea -- probably mostly because it was my idea :-) -- if I can convince myself (and my colleagues) that it doesn't create any unacceptable new risks.
Other ideas for creating greater transparency are welcome.
Hotword detection is optional in Android. If you don't like it, just turn it off.
The software which provides hotword detection on Android is also not auditable. How do you know it doesn't turn itself on when it detects that you're not looking at it, or monitoring it via adb? Oh no, I don't really think that it does either, but it's precisely the same concern as on Debian. You'd have to not install the google services to be sure you were avoiding it.
If that's your level of paranoia, you're lost, and omitting the Google services doesn't help.
The fact is that you implicitly and deeply trust all the companies in the production pipeline for the networked electronic devices you use, because absolutely any one of them can easily arrange for whatever sort of backdoor they want. It's a little tougher for the hardware component vendors, I'll grant, but if they do the work they're in the best position of all to compromise your security without any possibility that you could find it.
With Android specifically, though, I'm interested in ideas for how we can make the system more transparent. We can't do anything about hardware-level compromises, but I'd like it if the upper layers were more auditable -- and note that having access to source code that purports to be what's running on the device doesn't get you there.
One idea I've been toying with is a framework-level network tap that allows you to divert a copy of every bit that your phone sends or receives, via network, Wifi, bluetooth, NFC or USB, for your perusal and examination. Since most apps use the framework APIs for SSL, it should be possible to snarf this data before it's encrypted, too. Of course, there's a big downside: if this single data collection point exists, it will be a tremendously attractive target for compromise by other parties who want to see what your device sends or receives.
You're a smart person, do you have any ideas for what Android could do to make its operations more transparent? We can't achieve perfection, but if we could get it to the point where Google or anyone else in the supply chain would have to do something which is obviously and solely intended to hide their actions in order to exfiltrate private data, that would be great.
Note that this is not an idle question. I'm a member of the Android security team, and in a position to make these sorts of things happen, or at least dramatically increase the likelihood.
You only gave one example, and that one I found very quickly. I just searched for "elisp operators" and it was the second hit. Do you have better examples?
I look for all sorts of fairly obscure things and I really don't see the problem.
under NSL so they can't tell us.
National Security Letters can't give arbitrary instructions to suppress information. The law defines NSLs quite precisely. They are a form of subpoena and therefore can only be used to request information, with the additional constraint that the recipient of the NSL cannot tell anyone that the NSL was received or the information was provided. In addition, NSLs can only be used to request metadata, not content.
Maybe I'm not clever enough, but I can't think of any way that an NSL could be used to suppress stories. One could be used to demand information about who looked at stories, and Google wouldn't be able to tell anyone that the list of watchers was provided, but it couldn't be used to force the story offline.
There's also the possibility that the government is issuing secret gag orders which aren't so limited, but we have no evidence of that.
unplug it, or if its embedded, remove the audio driver for it, or set the 'volume' control so it cannot hear anything anyway. And put some tape over the little hole it listens through.
Now.. good luck doing that on your phone.... best just to remove the app (if you can) or trust Google not to have slipped this stuff into Android as part of its voice activation feature (for your convenience, of course)
Hotword detection is optional in Android. If you don't like it, just turn it off.
Google, seriously, when are you going to fix this?
It is fixed.
Google spends a lot of effort on optimizing search and has very sophisticated and effective metrics for tracking what works well and what doesn't. The thing is that you don't search like 99.99% of people search, and so the feedback loop optimizes away from you and towards others. Another poster above mentioned that it's better when signed in... I don't know if that's actually true, but Google does do some degree of search personalization, so it makes sense.
I find actually get very good results from Google, but I've changed the way I search. 20 years ago I learned to create very precise queries, with + and - to force and trim queries, omitting conjunctions and other common words that I knew weren't indexed anyway, etc. I don't do that any more. What works better these days, I find, is just to type a plain English question. For example, I just pulled up my Google search history, and here are some of my searches from today. Notably, not a single one of my searches required going to the second page of results and nearly all of them gave me the answer I was looking for as the top link.
"convert camelcase to underscore-separated with emacs" -- Got me immediately to a stackoverflow post that told me about the string-inflection package, available on MELPA.
"Can I use a heat pump to balance temperature between rooms?" -- My home office (I work from home) is perpetually hotter than the rest of the house, so I wondered if I could put a heat pump through the wall. Turns out, probably not. I'll investigate a fan instead.
"octal format string for printf" -- I didn't recall %o. Duh.
"example code for sha256 with openssl" -- Got me exactly what I wanted.
"how effective are hate crime laws" -- They appear to have no measurable effect on the rate of hate crime commission, though they arguably send a positive social signal.
"how to break on memory write in gdb" -- "watch"
"how to set gcm nonce length with openssl evp api" -- What a nasty hack that is, but it does work.
"trim whitespace from variable in bash" -- use tr
"bash tee to two pipes" -- redirect to a subshell
"942-Memory Training Error" -- Ugh, I think one of the DIMMs in my workstation is bad. Tech support is shipping me a replacement.
I only had the one error message to search for, but that's typical of my strategy. I don't try to craft an ideal query, I just paste the whole damned thing and 99% of the time I get an answer. Or at least more people complaining about the same problem.
I think a lot of the complaints about the change in search engine is from people who are still trying to use modern search engines they way they used them in 2000. Don't. Don't carefully craft your queries, just type a question, or paste a big pile of related text. That's what the masses do, so that's what Google optimizes for.
(Disclaimer: I work for Google, but not on search and don't know much about how it actually works.)
This is the right basic idea, I think, but I think everything will converge into a single device, either the mobile phone or a wearable. And as it becomes more and more central to everything we do, that device will become very smart about authentication.
The problem with using dedicated embeddable devices is twofold. First, the more of them you have to carry, the more difficult it is to keep track of them. With old-fashioned metal keys we've solved this with the key ring... but that creates its own problem. The more keys you add to it, the more valuable it becomes. Loss or theft become increasingly more problematic. And our metal keys open fewer, and less important, things than our electronic authenticators do.
So, it makes sense to combine the electronic keys in a single device, but then to use the capabilities it has that metal keys do not to solve the theft and loss problems. First, against loss, there must be a way of backing up all of the credentials, securely and automatically, so that in the event the device is lost they can all be recovered relatively easily. Some sort of remote server backup, to which you authenticate with some other mechanism that you protect very carefully (there are lots of options here, but a long, randomly-generated password printed out and stored in a safe place is a good option). That backup needs to be reliable and reliably accessible, but access need not be easy or convenient, since it should be rarely needed.
What about theft? This is where the smart device has huge advantages over dumber devices, because it can authenticate the user. This authentication needn't be particularly strong, but it should have good anti brute-force protections, and it should be smart. The goal is to make something that is extremely convenient for the user, but makes it relatively unlikely that someone else who gets it can use it. How could that work? Google is pushing towards this vision with Android Smart Lock features. The core idea is that the device shouldn't rely on a single signal, because that signal then has to be very strong.
It's worth looking at analogies with meatspace facilities that care a great deal about security. What they don't do is put a bank vault door on the exterior wall and rely on the strong combination lock to keep thieves out. Instead, they rely on layering of defenses, monitoring and active response.
What can your phone do? Quite a bit, probably. Not only does it have a touchscreen for entering passwords, it also has cameras, an accelerometer, GPS, various radios, compass, altimeter, microphones, a proximity sensor and probably other stuff I'm forgetting. In addition, it can know a lot about your habits, your plans (e.g. what's on your calendar) and more. With that wealth of signals, it should be possible for the device to determine with relatively high certainty whether or not it is still in your possession. Where it's uncertain, it can fall back to asking for authentication with, say, a fingerprint or simple PIN to increase its certainty. Or in more extreme cases, it can fall back to an even stronger password. The idea is to make authentication as seamless, transparent and automatic as possible... but as strong as necessary.
Or maybe a smart watch will be a better choice. It has pretty much all the same capabilities as a phone, but the advantage that you strap it to your body, making it harder to lose, and harder to steal. (Actually, I think over the next few years for many of us our phones will migrate onto our wrists; right now the smart watch is an extension of the phone, I think that will flip, with the handheld device becoming an extension of the watch providing a larger screen, aimable camera, etc.).
The "as strong as necessary" bit is important here, too. When the phone is going to use a stored authentication key to unlock something for you, the degree of certainty that it needs to have that you're you depends on what it's unlocking. If I'm using my phone to log me into slashdot on my laptop, I really cou
"Even then #ifdefs are the wrong way to do it. Create a system abstraction layer (or use one of the several excellent ones that exist) and call that. Then for each platform build and link the appropriate implementation of the abstraction layer. "
Sorry, I disagree. Abstraction layers are inefficient and add to bloat especially if the code only differentiates in a few places between platforms. I'm sure they look nice on a whiteboard design but in the real world they're rarely the best solution for home grown code.
Bah. Well-designed abstraction layers have no significant overhead. I've designed and built many of them.
So, is it more lucrative to claim the bounty, or exploit the bug?
Seems to me you can sell it to shady people for more money.
Only if you're the sort to do that.
It's the norm across the whole industry that the black market in vulnerabilities is more lucrative than the "white hat" side. And yet, it appears that the white hat industry is far larger -- and probably more effective. Why? Multiple reasons: Most people want to be honest, many of them like the public recognition they get from publishing, and there are a lot of risks in dealing with the sorts of shady people who pay lots of money for vulnerabilities. The net is that the best people almost invariably end up either on the white hat side.
Bug bounties have proven to be highly effective. How does the industry know? Simple: monitor the prices of black market vulnerabilities. Vulnerability Reward Programs tend to cause a spike in black market prices far out of proportion with the VRP payments. Partly this is because VRPs tend to sweep up most of the low-hanging fruit quickly, and partly it's because given the choice between getting $8K and a public "thank you" from Google, plus being able to publish and present, is a lot more attractive to many people than getting $50K from the Chinese. Or the NSA.
Not if it does a lot of low level systems calls. Unless you think win32 is going to work on Linux for example or Xlib will have no problem working on Windows.
Even then #ifdefs are the wrong way to do it. Create a system abstraction layer (or use one of the several excellent ones that exist) and call that. Then for each platform build and link the appropriate implementation of the abstraction layer.
The C++ committee has been aggressively removing all need for the preprocessor. Function-style macros should be inline functions. Macro-based code generation should be replaced with templates. Constants should be actual constants. About the only valid need left is for header inclusion (including guards) and C++ modules will eliminate the need for both of those (assuming they arrive in C++17).
I doubt that C++ will ever be able to actually deprecate the C preprocessor, but we're moving towards not needing it any more.
Also, the US admitted it and then said they weren't doing it anymore. That's kind of odd - normally a public admission backed by documentary evidence would be sufficient for a criminal prosecution, no?
No the US never admitted it. The White House said it wasn't being done at present (in 2013) and wouldn't do it in the future, but refused to comment on whether it had been done in the past.
Also, it's not a crime for countries to spy on other countries. More precisely, there is no international law making it illegal. Countries have laws against spying, but German courts can't usefully prosecute the the United States. Germany could prosecute the specific people who installed the taps, assuming they could identify and get hold of them (the US obviously wouldn't honor an extradition request).
The whole notion of "crime" is simply irrelevant here. This is a question of international relations, where countries punish those they believe do them ill by other mechanisms, ranging from subtle snubs to nuclear war, with lots and lots of gradations in between.
That's why so many people win the lottery.
The ones who see well into the future are the ones that create and operate the lotteries (and casinos, etc.), not those who play them.
Okay, you mentioned two things, and both of them were wrong, separately.
As the Lavabit case demonstrated, any company that didn't cooperate would no longer exist, and the public wouldn't necessarily know why.
Nonsense.
You're conflating several issues. In fairness, this misunderstanding is common.
What happened in the Lavabit case was completely different. There were no NSLs or gag orders, the sequence of legal events is in the public record, and shutting down was Levison's own decision. What happened was that Levison not only refused to comply with narrowly-targeted orders for one particular individual's e-mail, but lied, saying that it was impossible for him to comply. His bad faith ultimately resulted in a court order to turn over the keys, because the FBI successfully argued that they couldn't trust him to provide the requested material, and so had to get everything. I think the court was wrong, but there's no reason to assume that a company that employs attorneys and fights orders in the court system, rather than trying to fool the court, would see any similar order.
the Canada arctic
Er, the Canadian arctic, I meant to say.