If you like tinkering you might consider rooting and giving CM10 a try. Back when I used to do root & tinker there were ways, (once rooted, depending on the ROM), to block updates. Rooting is not everyone's cup-o-joe though, some prefer stock-like CM, etc., others like TouchWiz.
Also, nothing cheap about being prepaid.:) Once T-Mo get's their LTE house in order I plan to go back to them with whatever their prepaid / month to month BYOD plan is now.
Indeed what's interesting to me is the lack of a few anticipated things here. I havent followed closely but I thought the next update was going to be Key Lime Pie and was looking forward to a Nexus 5.
You misunderstood the analogy (I think). "Free Speech Zones" were nonsense created by the government intending to hide and push speech they didn't like to irrelevancy. The definition of censorship is not the point, but rather the act of pushing things off to a dark corner effectively stifling the content/speech is what is comparable here.
Notifications are per account (on Android Gmail) and you should be able to set up filters to skip the inbox for most messages except the ones you want in the gmail web interface. hth
You can disable Google Now (I think) and just use the search. Check the setting in Google Now, and/or try disabling the Google Now app itself from your device's main settings > apps.
Isn't that the point of these seeds though? They are designed to work with Roundup, thus he was using the product as intended? Except Monsato doesnt allow that.
Monsanto has a policy to protect its investment in seed development that prohibits farmers from saving or reusing the seeds once the crop is grown. Farmers must buy new seeds every year.
Also, I dont think you are correct. This is exactly what the court said was wrong. I also dont think it helped his case that he already had first purchased Monsato seeds, then went and bought cheaper mixed seeds in the hope of getting similarly resistant seeds (unclear from TFA how many, if any, were Monsato).
From TFA
[ Justice Elena Kagan said ] "Bowman planted Monsanto's patented soybeans solely to make and market replicas of them, thus depriving the company of the reward patent law provides for the sale of each article," she said. "Patent exhaustion provides no haven for such conduct."
Well, there are a few "interesting" gems there. Though it's mostly business fluff. From TFA:
Such companies as Facebook (FB) and Google also have special teams that review the lines of code written by developers. It’s these people who get to decide when a new feature is ready to make its way to their websites. Not LinkedIn. It has one, huge stash of code that everyone works on, and algorithms do the code reviewing. “Humans have largely been removed from the process,” Scott says. “Humans slow you down.”
Uh, Okay. Automated code review? Um, where to begin? I think there an obvious misunderstanding on the part of the author of the article. Surely Google, FB, et. al., do CI and all sorts of automated testing. They just *also* use humans.
Incidentally, Google clearly has more products, thus more specialties and codebases. FB also, to a lesser extent. I dont think the Google Search team is the same as the Google Maps team or the Android team.
LinkedIn is a website, they have an API, messaging, maybe some mobile apps? It's not trivial, but it's probably not very close to the technical complexity of FB, and no where near the technical complexity of Google.
LinkedIn initiated Project Inversion to fix its issues and has since evolved into one of the poster children for continuous development
...by stopping all continuous dev so they could rebuild from scratch...
I think TFA misses the point in a very "PHB way" sadly. They took the time to make the devs happy and give ownership of features to devs. The result was the devs created an environment that was productive and could be continuously updated with less fuss.
To me, this is the poster child for creating a dev focused culture, and taking the time to do things the right way. Which, sadly, is the exact opposite of the conclusion of TFA and the LinkedIn PHB.
Luckily the Barns & Noble case revealed some of what MS has been hiding. I dont have the info top of mind, but IIRC it was a lot of nonsense related to calendar syncing.
I'd rather see someone side-step Verizon. They seem to have the LTE network to beat. Good for HTC though, every little bit to weaken carrier grip is welcome, be it from HTC, Apple, Google, or whoever.
why is SD card access a boolean decision? And why are all permissions granted permanently to apps?
Fair questions, but how would you have designed it? Think carefully about the edge cases and user experience for both questions. I think it also helps to keep in mind lessons learned from incessant dialogs. Users are now desensitized and trained to click OK, despite not having read the message.
You know, I got that same feeling when the article said this was from "Russian security firm Doctor Web" and the malware dates back to October 2012.
They may be legit, but I did a double take on the name and country of the company, as well as the date.
Looks like it comes from TFA, which is next to useless for actual helpful information. No mention of what ad networks, or what apps theses were found in. They even blur the website name of where they encountered an ad. The Next Web article seems to be copy-pasta from the AV 'article' (probably better described as a press release). I clicked around their site and their links are broken and redirect to a scary 404 page that gives me instructions on how to recover Windows. Pot, kettle, anyone?
But sure enough, they sell Android antivirus software.
(Full disclosure: I sell an app meant to teach new users about Android permissions, but also give the text of the guide away -- still, take what I say with a grain of salt, like anyone else).
This is something I have been hoping to get time to write for awhile, more of a Wiki with statistics of how apps creep in their permission usage. Basically a community informational tool. Unfortunately I haven't had the time, nor much server coding experience. (If anyone is interested in contributing please feel free to contact me through my website).
And while your cynical take on the "developer first market" is not far off the mark, I think we should remember that there is a social contract between dev and user. I write a program and you pay me to buy it, or look at ads to use it. This part isn't really one sided at all. The problem is actually that permissions are granted before the user has a real chance to evaluate the application. This puts the users on the defensive.
I think if the social contract between dev and user was something agreed to at the time a feature was used, that would be better. It would put both dev and user on equal ground. If an app dev needs that permissions (for technical or business reasons), and they are denied it, they can shut down the app gracefully. If a user wants to deny some overreaching, they can also do so. With this case, either side can walk away at any time.
However, when the OS starts spoofing data (like the IMEI) in place of things (ala the rejected cyanogen patch), it breaks that contract both figuratively, and possibly literally. (For example if the user has agreed to TOS, and is now breaking them). I worry as a user that if we ever hope to have a system by which we retain control over permissions, we cannot break the contract, it will start a arms race (akin to ad blocking on websites).
What we need is to give users better tools to push back against permission creep, and for devs to have opportunities to cut back to what they really need.
It's not a contest -- the fact that iOS handles it well is a good thing. But it doesnt change the fact that what tepples said was also correct (though seems deprecated AFAICT). This was unfortunately the problem with that permission. It had very legitimate uses, and very nefarious ones too.
Nevertheless, you brought up the comparison to iOS. So kindly spare us the "only on slashdot" stuff when it was you who seemed to be spoiling for a brand fight.
Games should not need it. Any time the host activity is paused the games should pause any background processing. Media players, especially music players do play in the background, even with the screen off though. So for them, it is a must.
The permission is too coarse though. They need to separate state and identity. Unfortunately they've dug a backwards compatibility hole pretty deeply though at this point.
Screen calls? Eventually the app could answer and have the conversation we were going to have. Also there will be apps to make calls for us based on what we're thinking. If all goes well, these apps will call each other and have the entire conversation without us. I hope it is an interesting conversation!
I wonder if they will get their own facebook accounts....
It used to send a generated email such as 2r3qw-45co-i987@checkout.google.com (at least for some orders) so you could contact the customer if you needed to. But as of a few minutes ago it seemed my sales were listing real emails for all the orders I checked (just a few). So I'm not sure if they have these generated emails anymore or not. (I suppose it's possible they started getting spammed at addresses like that).
As a dev I don't think this is ideal. I liked the generated email solution. (I'm not sure how that worked exactly, I always got a mix of generated and real emails). But I don't think this is as terrible as people are making it out to be. They are not giving out the credit card number or embarrassing photos of you as a kid or anything. They provide the merchants with name, account age, coarse location (zip/city), email address, and email marketing preference: opt in/out.
They also do send the user a receipt email that describes the transaction as being between the customer and the developer.
It looks like this:
Thank you. You've made a purchase from [developer ] on Google Play. Order number: (.....) Order date: (.....) Payment method: (.....)
Questions? Contact [developer's email]
See your Google Play Order History. View the Google Play Refund Policy and the Terms of Service. Need help? Visit the Google Play help center.
So the questions are: How should it be presented to the user? What level of information should a merchant have?
Keep in mind the system supports web merchants and carrier billing. Should there be multiple systems?
I'm not sure I know the right answer or even what all the logistical issues are. Personally I use Google wallet to buy "cloud" backup services and other stuff not related to Android. In some small ways this affords me more privacy from the vendor than if I had just bought directly with a credit card.
Anyways as a dev it's interesting to have some level of geographical data. Names are helpful for dealing with customers. Emails are good for support. But I'd definitely like the customer to know what they are getting in to./incidentally if Google wants to just act like a payment processor they could charge a more reasonable rate ( 5% ? ):)
Slashdot Mirror
If you like tinkering you might consider rooting and giving CM10 a try. Back when I used to do root & tinker there were ways, (once rooted, depending on the ROM), to block updates. Rooting is not everyone's cup-o-joe though, some prefer stock-like CM, etc., others like TouchWiz.
Also, nothing cheap about being prepaid. :) Once T-Mo get's their LTE house in order I plan to go back to them with whatever their prepaid / month to month BYOD plan is now.
Indeed what's interesting to me is the lack of a few anticipated things here. I havent followed closely but I thought the next update was going to be Key Lime Pie and was looking forward to a Nexus 5.
The new support library seems interesting though
You misunderstood the analogy (I think). "Free Speech Zones" were nonsense created by the government intending to hide and push speech they didn't like to irrelevancy. The definition of censorship is not the point, but rather the act of pushing things off to a dark corner effectively stifling the content/speech is what is comparable here.
Notifications are per account (on Android Gmail) and you should be able to set up filters to skip the inbox for most messages except the ones you want in the gmail web interface. hth
In Soviet Russia, you power battery?
(this almost seems like a setup!)
It's more of a list view/ grid view. I'm curious in particular what do you think is bad UX ?
You can disable Google Now (I think) and just use the search. Check the setting in Google Now, and/or try disabling the Google Now app itself from your device's main settings > apps.
Isn't that the point of these seeds though? They are designed to work with Roundup, thus he was using the product as intended? Except Monsato doesnt allow that.
Monsanto has a policy to protect its investment in seed development that prohibits farmers from saving or reusing the seeds once the crop is grown. Farmers must buy new seeds every year.
Also, I dont think you are correct. This is exactly what the court said was wrong. I also dont think it helped his case that he already had first purchased Monsato seeds, then went and bought cheaper mixed seeds in the hope of getting similarly resistant seeds (unclear from TFA how many, if any, were Monsato).
From TFA
[ Justice Elena Kagan said ]
"Bowman planted Monsanto's patented soybeans solely to make and market replicas of them, thus depriving the company of the reward patent law provides for the sale of each article," she said. "Patent exhaustion provides no haven for such conduct."
Well, there are a few "interesting" gems there. Though it's mostly business fluff. From TFA:
Such companies as Facebook (FB) and Google also have special teams that review the lines of code written by developers. It’s these people who get to decide when a new feature is ready to make its way to their websites. Not LinkedIn. It has one, huge stash of code that everyone works on, and algorithms do the code reviewing. “Humans have largely been removed from the process,” Scott says. “Humans slow you down.”
Uh, Okay. Automated code review? Um, where to begin? I think there an obvious misunderstanding on the part of the author of the article. Surely Google, FB, et. al., do CI and all sorts of automated testing. They just *also* use humans.
Incidentally, Google clearly has more products, thus more specialties and codebases. FB also, to a lesser extent. I dont think the Google Search team is the same as the Google Maps team or the Android team.
LinkedIn is a website, they have an API, messaging, maybe some mobile apps? It's not trivial, but it's probably not very close to the technical complexity of FB, and no where near the technical complexity of Google.
LinkedIn initiated Project Inversion to fix its issues and has since evolved into one of the poster children for continuous development
I think TFA misses the point in a very "PHB way" sadly. They took the time to make the devs happy and give ownership of features to devs. The result was the devs created an environment that was productive and could be continuously updated with less fuss.
To me, this is the poster child for creating a dev focused culture, and taking the time to do things the right way. Which, sadly, is the exact opposite of the conclusion of TFA and the LinkedIn PHB.
For anyone else who hasn't heard that term before: http://en.wikipedia.org/wiki/Vitality_curve
Luckily the Barns & Noble case revealed some of what MS has been hiding. I dont have the info top of mind, but IIRC it was a lot of nonsense related to calendar syncing.
LED's do not emit a sense of humor.
LED's don't emit a 'whooshing' sound (unless you catapult them or use a trebuchet)
I'd rather see someone side-step Verizon. They seem to have the LTE network to beat. Good for HTC though, every little bit to weaken carrier grip is welcome, be it from HTC, Apple, Google, or whoever.
why is SD card access a boolean decision? And why are all permissions granted permanently to apps?
Fair questions, but how would you have designed it? Think carefully about the edge cases and user experience for both questions. I think it also helps to keep in mind lessons learned from incessant dialogs. Users are now desensitized and trained to click OK, despite not having read the message.
You know, I got that same feeling when the article said this was from "Russian security firm Doctor Web" and the malware dates back to October 2012.
They may be legit, but I did a double take on the name and country of the company, as well as the date.
Looks like it comes from TFA, which is next to useless for actual helpful information. No mention of what ad networks, or what apps theses were found in. They even blur the website name of where they encountered an ad. The Next Web article seems to be copy-pasta from the AV 'article' (probably better described as a press release). I clicked around their site and their links are broken and redirect to a scary 404 page that gives me instructions on how to recover Windows. Pot, kettle, anyone?
But sure enough, they sell Android antivirus software.
(Full disclosure: I sell an app meant to teach new users about Android permissions, but also give the text of the guide away -- still, take what I say with a grain of salt, like anyone else).
This is something I have been hoping to get time to write for awhile, more of a Wiki with statistics of how apps creep in their permission usage. Basically a community informational tool. Unfortunately I haven't had the time, nor much server coding experience. (If anyone is interested in contributing please feel free to contact me through my website).
And while your cynical take on the "developer first market" is not far off the mark, I think we should remember that there is a social contract between dev and user. I write a program and you pay me to buy it, or look at ads to use it. This part isn't really one sided at all. The problem is actually that permissions are granted before the user has a real chance to evaluate the application. This puts the users on the defensive.
I think if the social contract between dev and user was something agreed to at the time a feature was used, that would be better. It would put both dev and user on equal ground. If an app dev needs that permissions (for technical or business reasons), and they are denied it, they can shut down the app gracefully. If a user wants to deny some overreaching, they can also do so. With this case, either side can walk away at any time.
However, when the OS starts spoofing data (like the IMEI) in place of things (ala the rejected cyanogen patch), it breaks that contract both figuratively, and possibly literally. (For example if the user has agreed to TOS, and is now breaking them). I worry as a user that if we ever hope to have a system by which we retain control over permissions, we cannot break the contract, it will start a arms race (akin to ad blocking on websites).
What we need is to give users better tools to push back against permission creep, and for devs to have opportunities to cut back to what they really need.
It's not a contest -- the fact that iOS handles it well is a good thing. But it doesnt change the fact that what tepples said was also correct (though seems deprecated AFAICT). This was unfortunately the problem with that permission. It had very legitimate uses, and very nefarious ones too.
Nevertheless, you brought up the comparison to iOS. So kindly spare us the "only on slashdot" stuff when it was you who seemed to be spoiling for a brand fight.
Correction: I'm not sure media players even need it either as of API 8:
http://developer.android.com/training/managing-audio/audio-focus.html
Each app is run under a separate linux user process and is a separate instance of the dalvik VM.
I'd be curious your definition of sandboxing.
http://android.stackexchange.com/questions/42129/why-each-android-application-runs-on-a-different-dalvik-vm-process
Games should not need it. Any time the host activity is paused the games should pause any background processing. Media players, especially music players do play in the background, even with the screen off though. So for them, it is a must.
The permission is too coarse though. They need to separate state and identity. Unfortunately they've dug a backwards compatibility hole pretty deeply though at this point.
When I clicked your link I was hoping to find some delicious sirloin or ribeye steaks for sale. :(
"To pair with MindReadr (TM), just think the number 2643. To dismiss, don't think of those numbers"
Crap!
Screen calls? Eventually the app could answer and have the conversation we were going to have. Also there will be apps to make calls for us based on what we're thinking. If all goes well, these apps will call each other and have the entire conversation without us. I hope it is an interesting conversation!
I wonder if they will get their own facebook accounts....
It used to send a generated email such as 2r3qw-45co-i987@checkout.google.com (at least for some orders) so you could contact the customer if you needed to. But as of a few minutes ago it seemed my sales were listing real emails for all the orders I checked (just a few). So I'm not sure if they have these generated emails anymore or not. (I suppose it's possible they started getting spammed at addresses like that).
As a dev I don't think this is ideal. I liked the generated email solution. (I'm not sure how that worked exactly, I always got a mix of generated and real emails). But I don't think this is as terrible as people are making it out to be. They are not giving out the credit card number or embarrassing photos of you as a kid or anything. They provide the merchants with name, account age, coarse location (zip/city), email address, and email marketing preference: opt in/out.
They also do send the user a receipt email that describes the transaction as being between the customer and the developer.
It looks like this:
Thank you.
You've made a purchase from [developer ] on Google Play.
Order number: (.....)
Order date: (.....)
Payment method: (.....)
Questions? Contact [developer's email]
See your Google Play Order History.
View the Google Play Refund Policy and the Terms of Service.
Need help? Visit the Google Play help center.
So the questions are: How should it be presented to the user? What level of information should a merchant have?
Keep in mind the system supports web merchants and carrier billing. Should there be multiple systems?
I'm not sure I know the right answer or even what all the logistical issues are. Personally I use Google wallet to buy "cloud" backup services and other stuff not related to Android. In some small ways this affords me more privacy from the vendor than if I had just bought directly with a credit card.
Anyways as a dev it's interesting to have some level of geographical data. Names are helpful for dealing with customers. Emails are good for support. But I'd definitely like the customer to know what they are getting in to. /incidentally if Google wants to just act like a payment processor they could charge a more reasonable rate ( 5% ? ) :)
The warning shot?