Those kind of tasks would go in the online calendar, scheduled on some future date.
> The one outside tool I use is an online calendar, and I put everything on this calendar, even things that aren't actually for a fixed time like "make a coffee table at the workshop" or "figure out how to recruit new PhD students" — I'll schedule them on a date when I want to think about it. That way all my future plans and schedule are together, and not a bunch of lists I have to keep track of.
I had a similar experience as the author I broke my cell phone in Chongqing, China. If you have a chance to go to China, I highly recommend it. The society is just so different there, and it's incredible in so many ways.
You may be able to do it without speaking Chinese, but it would be much more difficult, and I'd be afraid of mutual misunderstanding of what I wanted the repairperson to do.
I learned the basics of Chinese before I went to the country, and took an intensive course in Mandarin the first time I went there.
I think learning a new programming language is more about logic. There's not a lot of memorization, but you need practice (some need it more than others) to make the connections. After learning one programming language, other languages may have different structures, but the logic required is not all that different.
In my experience learning Chinese, there's no shortcut to putting the hours in and memorizing vocabulary. I think this is even more true for Chinese than most other languages.
Learning a new programming language is difficult mentally. Learning a new human language is extremely tedious, but I think anybody can do it if they put in enough time.
I think this is even more true for Chinese than most other languages.
Commonsense indicates the difficulty of learning a language doesn't depend solely on the language in question, but on how similar it is to languages you already know. An extreme example is that if you already speak Mandarin, learning Mandarin is a no-op. As a less extreme example, I'm sure that learning Mandarin is easier for a Cantonese speaker than for someone who only knows English and French.
Commonsense does suggest that, but I've heard such a wide variety of people with different linguistic backgrounds say that Mandarin was the hardest language they learnt that I'm inclined to believe there is some real underlying difference.
Well, considering that Chinese is mostly a linguistic isolate, that doesn't necessarily contradict the thesis. Japanese has a writing system and a lot of vocabulary borrowed from Chinese, and I know less about Korean but I think it also has plenty of vocabulary borrowed from Chinese. Do any of your friends natively speak one of those languages and still consider Mandarin more difficult than, say, English?
I'm a Chinese, and I can easily understand written kanji (one of the 3 Japanese writing systems) as it's essentially traditional Chinese characters, but the pronunciation is a whole different game altogether. From this I'm assuming that it's the same for Japanese speakers to recognise some Chinese characters, thus making it easier for them to learn.
In Japan, you learn both Japanese and Chinese readings for kanji. Except the Chinese readings in China are different to the ones in Japan. A lot of people thought I was strange when I was pointing things out on a menu, but couldn't say what they were. lol
Wait so the Chinese reading in Japan is different from the Chinese reading in China and most parts of the Chinese speaking world (ignoring the influences of accents)?
方法 (method)
In Chinese: fāngfǎ "FONG-fah"
In Japanese: houhou "HOE-hoe"
日常 (everyday, ordinary)
In Chinese: rìcháng "ZI-tchong"
In Japanese: nichijou "NEE-chee-joe"
七月 (July)
In Chinese: qīyuè "CHEE-yue"
In Japanese: shichigatsu "SHEE-chee-gah-tsoo"
(Yes, 'shichigatsu' is seriously the Chinese reading of July; the Japanese reading would be 'nanatsuki'.)
And some that are similar:
開始 (start)
In Chinese: kāishǐ "KAI-tsi"
In Japanese: kaishi "kai-shee"
第三 (third)
In Chinese: dìsān "dee-SAN"
In Japanese: daisan "dai-san"
(Note that the pronunciation guide is somewhat approximate since certain sounds don't map well and English vowel pronunciation is a mess.)
I've heard that the Japanese on'yomi (Chinese) readings are generally closer to Old Chinese than modern Chinese is. Also, notice that Chinese is tonal and Japanese isn't.
Google seems to have no interest in protecting android users from this either.
There was an app called 'App Ops' that gave android users the ability to choose which permissions they wanted to grant applications. No root required.
Get too many notifications from an app, or don't need location functionality? You used to be able to turn these features off one-by-one for each app. You could also see the last time an app used location services. Android developers have a bad habit of requesting every permission under the sun, so I've gotten in the habit of disabling the permissions that don't add value for me.
Unfortunately, Google later removed this feature saying that its release was accidental. I thought it was a clean solution to a major problem.
Why wouldn't Google want users to have such powerful control over their devices? It's always explained like this: Because it's "simpler." Because "things will break if the user does something wrong." Because "the average user won't need it."
Those same poor excuses have been responsible for so much loss of privacy and freedom elsewhere, not just by Google. To me, they're deliberately preventing users from having too much power to control their devices, so they can better persuade them in the direction they want. Then they accidentally gave the users too much, so of course they would say it wasn't intended, but the reaction certainly says that it's precisely what the users want...
Or, rather, it could be because the feature was unfinished and tended to crash applications when they don't get the stuff that's called for (and the user authorized) on the permission manifest.
I'm a user/dev on the iOS side, and you're definitely right that apps need to be coded to specifically handle cases where they don't get permissions, but...
...this stuff is critical! Give the user the control, let them break the apps that are over-using permissions, and let the apps update to fix.
You can do this in a pretty intuitive, nice way too -- include a flag in apps that says they've been updated to handle partial permissions correctly, and then if an app that hasn't been updated crashes w/ reduced permissions, throw up a dialog explaining that (1) the devs need to update the app (2) if the app not crashing is critical for the moment, the user should lift the permissions restrictions.
Arguments for "simplicity" seem unconvincing to me -- you want to avoid non-essential complexity to achieve simplicity, but this stuff is important to all users.
The app receives an empty address book (as opposed to NO address book), an empty calendar (as opposed to NO calendar), and in your location case, the app gets the "rough" location provided by the cell network.
Throw nulls (or better yet, exceptions) where an application expects parseable data (and given the current permission paradigm, has every right to expect usable data) and you can very reasonably expect breakage.
This is why the feature needs to cook for longer, not some malice aforethought on Google's part as GP claims.
I don't think you're understanding what I'm suggesting.
Yes, throw nulls if the APK identifies itself as supporting App Ops. If it doesn't, well, of course it's going to break when you throw nulls at it. Build a compatibility layer as I described above, and the app will continue to get parseable data when it requests parseable data.
This is about the easiest change for developers to accommodate. All they need to do is handle one exception.
Most of the permission bloat on Android comes from ad network libraries that do a crappy job of behavioral targeting anyway. Turning off that kind of obnoxious data exfiltration isn't going to hurt anyone, least of all the user.
I don't recall there being an outcry over how painful it was to use permission revocation.
How do you provide random dummy data for a Contact List permission without a) running the risk of crashing the app, or b) making it obvious to the app that it's receiving dummy data?
Is android supposed to return a well structured list of fake names and emails? Would instagram show me a list of made up names and user id's if I faked my contacts?
1. An app asks for permission to access my contacts
2. I decline to give permission
3. The app churns for a few seconds, then suddenly returns a list of names that i have never seen before, including fake numbers and addresses (a list of fake names would be too easy to detect as a fake response).
Erm, no they should not. The same breach of privacy will occur when an app just re-implements the demanding of a permission. "This camera app will not run without access to your list of contacts. Enable Contact List Access and restart to proceed".
If the phone is mine, then I should be able to easily set it to lie on my behalf to protect my interests.
On iOS you can disable any permission at any time for any application and it's plainly explicit in the API. I've never seen any application do what you describe.
The typical example people make is Facebook, which they assume would block you if denied your location but instead works just fine when you remove access to location, camera, photos, and contacts. I don't see why they would behave differently on Android.
For the straightforward example I gave there would be a backlash, especially for the bigger names. But that doesn't mean it's a stable situation, or that other examples wouldn't escape outrage in a different context - "This video can only be played if you enable Location Permission so that we can verify you are in the correct region."
The goal when designing an interface should be to get it right, not to make something that works for now but will just have to be patched up again later. For many permissions, it would be advantageous for the user to not even outright deny, but to return a subset or otherwise modified data - only one contact group, fixed location data, filtered Internet, etc. This of course sounds like heresy to app developers, and that's exactly the point - it's the user's device.
If the only goal was to preserve privacy in 2014, then you would be correct. However, the actual goal is to preserve privacy in the future, so the current state is not the final word. Instead, we must use our intelligence to predict what can happen in the future, so that we may preempt those problems before they become widespread.
That's not a breach of privacy. That's the developer enforcing their TOS. It is within my right to say that if you won't give me location information for (ad targeting/basic functionality), you can not use my app.
Which is fine, but I'd also expect one-stars for that kind of behavior.
> It is within my right to say that if you won't give me location information for ad targeting, you can not use my app
I disagree. That question is exactly what we're discussing here. What you just said clashes with what you said earlier:
> Apps are guests in the user's back yard, not the other way around.
Either a developer is able to enforce their desired "TOS" on the user's device, or they cannot.
I am on the side of cannot, because attempting to define morals through simple rules ("right to contract") and then asserting that all emergent behavior from those rules is just, fails extremely hard with complexity-induced contradictions. The whole idea behind saying that a user owns the device is to make it clear that the Schelling demarcation point is the protocol, with each party carrying out such in their own best interest. Assuming an ambient authority (a legal contract, in this case) that constrains the behavior of the user's device runs directly counter to this.
That doesn't clash at all. It's maximal freedom on both sides - you decide under what terms the developer's program runs. If the developer doesn't like those terms, the app doesn't run.
Either the user accepts the developers desired TOS on their device, and they get to run the app, or they do not.
I'd go a lower level than the legal contract. If the app says it wants X to run, and you deny X, the app is under no obligation to run. Your back yard, their code.
As soon as it is on your device, it is no longer the developer's program, but your copy.
Ownership (as opposed to renting) enables distributed rights instead of centrally-granted privileges. Hoping that competition between centralized privilege-granters will compensate for a lack of true rights is an error based in the fallacy of efficient markets.
In reality, competition/enforcement is not perfect and defaults matter. To expand on the example I just gave, Honda could indeed require me to sign a contract saying I will not use the car to drive to a Toyota dealer. But with no way of stopping me, their only recourse is to exert resources bringing me to court. To be motivated to do so, they must be actually suffering real harm rather than a mere general desire of trying to prevent competition. So ridiculous ideas like that end up laughable non-starters rather than ever present niggling restrictions that are too numerous to fight.
Which is fine and dandy, just don't expect Google's or the developer's help to do so. I'll say it again - if one of the terms I license (sell a license) my app under is that it must have location data, you are entitled to either provide that data or not use the app.
Yes sure, but you're just referencing the knows-best authoritarian thought that has gotten us into this mess in the first place. The current state of the "art" doesn't change what is right, so you're merely pointing out that Google's developers are not working to preserve users' freedom.
I'll say it to be clear - regardless of what you think your "terms" are, they're irrelevant to the functioning of my computational devices.
It's not constraining the behavior of the user's device, it's constraining the functionality of the app. If an app needs certain permissions to function, and the user denies those permissions, why should the app be forced to run with falsified data?
Imagine that the use case is not ad targeting, but rather emergency weather broadcasts based on your location. Do we still want the app to receive randomized data?
If the user configures the emergency weather broadcast app to receive randomized data, yes obviously.
The app should be "forced" to run with modified data, because that is what the user explicitly chose. The whole point of an app is that it runs on the user's device, meaning it should be ultimately acting in the user's best interest, despite any post-facto desires of the developer. That is the whole idea of ownership - I can drive my current Honda to browse for new cars at the Toyota dealership, etc.
What would happen when the aforementioned emergency weather broadcast app fails to notify users of a tornado coming their way, because it was given the wrong locations? What would that do to the app's reputation? How many people would believe it's user's fault as oppose to blaming the shitty app?
By your logic, a laptop with li-ion battery can be "forced" to keep running in an 140F degree environment, because that's what user "explicitly chose". When it explodes, who's getting the blame?
There's something call operational envelope, which applies to software too. And believe it or not, that is for user's "best interest".
Or when the user's location reporting is off, or their network has been firewalled, or they're 60 miles away at work but really would have liked to know that a storm was coming for their house?
I mean sure, you may face some public outrage. On the other hand, you may have to deal with a twitstorm for any number of other ridiculous reasons. Should the ideal really be to give everyone safety scissors because you're worried about the rare dolt that doesn't know which end to hold? That's the kind of attitude that dumbs the whole of society down and fuels the entitled mob who blames everyone else for their own mistakes.
What you called the user's "best interest" is based on know-it-all paternalism. For 90% of things it will agree, but don't mistake your model user's utility function for actual individuals'.
(And for your li-ion example, there's a reason that's done with a thermal fuse instead of software, which means that the design is fixed. But to the extent that it is done in software instead, then yes it should be end-user adjustable, even if it seems like a really bad idea for them to do so)
I'm not sure denying an app permission to use your data is the same as explicitly choosing to provide that app with randomized data.
If you want to ensure that the system is only doing what the user explicitly chose to do, you need to provide prompts that let the user explicitly choose to provide randomized data.
And at that point, we're probably better off just returning nothing.
It's not really hard.. one choice with a multitude of options:
Choose Level of Location Access:
1. Full access (exact location)
2. Nearest [major intersection, city, state]
3. Fixed location [home, work, present location, choose from map]
4. Random walk [choose area from map]
5. Ask me every time
6. Deny
Go ahead and default/emphasize the most-desired and least-confusing options so that fewer mistakes are made. But treating users like children and restricting their options in the name of 'usability' is downright wrong. Your average person seems quite dumb due to disinterest, but give them options and abilities they didn't know they could have, and watch as their interest perks up.
> This is about the easiest change for developers to accommodate. All they need to do is handle one exception.
One exception, possibly in hundreds of different places in the code. What a ridiculous assumption to make: "just about the easiest change"? Seriously?
Adding real permission revoking into Android at this point is a total no-go. The real solutions to this issue are App Ops (which transparently stubs out API's by returning blank data or simply ignoring calls) and optional permissions (for developers) in cases like temporary access to contacts.
Both already exist in the AOSP codebase in one way or another. Only the settings UI for app ops is gone, and optional permissions are under work [1].
I would bet money it has to do with business decisions that relate to carrier demands to support Android. People forget that Android is not in the same position as iOS to impose its will on carriers. Rather, the power dynamics are rather significantly the opposite, Android has to do far more negotiation and accommodating to assuage carriers.
Unfortunately, with the waning and sobering infatuation with iPhones and iOS, I have a sense that iOS will start and maybe even has made concessions that it otherwise would not be willing to. We have to realize that as long as network carriers are not what they should be, dumb pipes for data who make their money simply on competitive network performance, we are all subject to a protection racket type dynamic.
That's exactly the reason, and it's more legitimate than you give it credit for. I can foresee numerous situations where users disable location tracking (in the name of saving battery) without realising the effect it will have (rendering a location-based app useless).
A nice middle ground would be to keep App Ops, but hidden away somewhere, much like the Developer Tools are.
So I have an application which can attach location information to posts made from it. It requests access to location data (as is necessary) when installed, then lets you turn that feature on or off from an internal setting.
The request for location data implies the usage of the location feature, so the Android package manager won't let you install it on devices without a coarse location provider.
Therefore, like most Android apps which lookup location information, it just assumed that it could do location lookups. No point testing for a feature which will always be present, right?
Now guess what would happen if you used AppOps to turn location off? That's right, it would crash.
Not exactly acceptable user experience.
Now, what Google should do is probably:
* For apps targetting Android 4.5+, certain features with privacy implications will default to OPTIONAL rather than REQUIRED when implied by a permission request.
* AppOps is then able to toggle access to features which are declared optional, which apps must handle the absence of anyway.
Any programmer worth their salt should, whenever doing any sort of IO (regardless of hardware, cloud, or otherwise) should be making sure they get a sane result/object back. Purely anecdotal here, but I run XPrivacy and have the vast majority of my apps blocked from location. You'd think my phone would barely work, but it actually works fine. I don't think I've ever had an application crash from lack of GPS.
Part of why they don't crash is the multi-threaded nature of how the location API works in Android. High level: you basically of instantiate the location object at the start of your thread, and give it a call back function to call once it has a location for you. You don't know when/if you will ever get a callback, so you have to put some checks in.
Because given away for free to generate traffic on google properties, therefore Google will not ship features in Android that would be detrimental to the monetization of an android user by allowing them to control their privacy.
Personally, given the existing complexity of Android I find it funny that they said it would make things too 'complex' to give users control of their privacy.
It was never released -- they removed access to a feature that was not intended for the public. That seems well within their right. For you to declare "Google seems to have no interest in protecting android users from this either." seems quite misguided, given that they are clearly working on a solution for this exact problem.
Android's source code has been gaining AppOps runtime permission checks for a while now. It really does look like they're moving towards a runtime permissions model.
The AppOps "release" wasn't a release. It was a private screen that accidentally had a public intent filter (default behavior is public, this is an easy thing to miss). The only reason anyone knows about it is because people made "launchers" that opened the screen, it was never reachable by normal means.
No it just means that there is permissions infrastructure not that they intend to make it available.
What would show Google working actively would be to modify APIs or provide solid guidelines for developers to ensure that arbitrarily closed permissions didn't cause an app to crash or freeze. Making app privacy a high priority for future Android development would be clearly working towards it.
Having a hidden privacy infrastructure means nothing at all.
Multiple user account had a similar pre-release. It wasn't initially meant to be seen, but the crafty users a lot of Android developers are, we figured out how to start using it. A future update of Android made it a regular feature. Same with Apps2SD, although the community design wouldn't work for most users, the Android saw value in the project and came up with a solution that was more user friendly.
I wouldn't be surprised if Android v.next had this feature built-in, but it might require a newer API version.
In a sense it already does: there were instances of Ingress players "moving" from place to place at 200km/h or so during rush hour in London.
IMHO it's better if developers know about fake data so they can factor them in, using plausibility checks. As is, they seem to assume that the data source is real.
What really disappoints me is the terrible placement Google uses for privacy features in the Play store. They're really hidden away instead of being prominent searchable fields. Microsoft of all companies does far better with their Windows Store.
I would agree with you except for the part where they force you to see them before you're allowed to even install an app. It's hard to get much less hidden than that.
It's not particularly useful if the permissions aren't displayed on lists and aren't searchable. The only option now is a brute force search by hand, clicking Install on each app in a category until you find a version of 2048 that doesn't demand SD card, camera, and full net access...
This would be my biggest problem, I think it's just nuts: "all travellers transiting in the USA using either a transit visa or the Visa Waiver Program will be photographed and fingerprinted."
Shareholders with voting shares have the right to attend shareholders meetings and vote in the board of directors. In such large corporations, shareholders usually appoint a proxyholder who attends the meeting and votes on the shareholder's behalf.
My understanding was that Nokia Plan B was basically soliciting such proxies by asking shareholders to give their votes to them for the purpose of replacing the board.
Corporate law usually doesn't require a proxyholder to be a shareholder, so they actually didn't even need such a (weak) claim to authority.
As a side note, soliciting proxies usually requires following proper corporate law procedure by sending prescribed materials. Nokia Plan B just had a website, which was an early indication this was a fake.
From what I've heard:
* If you paid by google checkout, you were never actually charged
* If you paid by paypal, you should have been refunded by August 17th, 2010 (http://blog.wakemate.com/2010/08/17/timing-update/)
So if you paid by paypal, just check your transaction history around that date to ensure you actually got the refund.
> The one outside tool I use is an online calendar, and I put everything on this calendar, even things that aren't actually for a fixed time like "make a coffee table at the workshop" or "figure out how to recruit new PhD students" — I'll schedule them on a date when I want to think about it. That way all my future plans and schedule are together, and not a bunch of lists I have to keep track of.