Right, but have you gone into the game after changing IPs? Do you have a static/semi-static IP? Or dynamic?
Doesn't much matter *when* you are online --I'm saying as soon as you do go online it could be possible that if some component of the game, or even game/store client (I don't know if Steam or Origin do this) creates P2P connections. After changing IPs, as soon as that game/game client creates a new P2P connection, it's possible the attacker then knows your new IP.
Again, all depends on the game/client and I dont know which ones use P2P style networking to connect users.
It's also possible, though maybe less likely that if the game they are playing creates P2P connections between the players for say chat, then they could be revealing their IP that way. Like Freshly Exhumed said above though, it all just guesses without some evidence.
But what do I know, I'm a packet who got lost on his way to 127.0.0.1
It seems Google Apps accounts are opted out by default, but Gmail and other regular Google accounts may be opted in by default.
Still, they have made it very clear how to turn it off, and you would still need to comment, +1, or follow something for "Sharing" to kick in. I can kinda see how it's a nuisance, but they are being very up-front about it and making sure all user are notified via several notification methods.
I'm more bothered by the half-assed attempt to tie my Google account and real name to things like YouTube. Those prompts are (still) down right infuriating (and buggy, a few times I thought it might have change my YouTube account name).
This however, is hardly a blip for me. (Although to be fair, I use an Apps account).
You might look at a Moto X -- nearly the same performance in a smaller form factor. (Smaller than the Nexus 4, and Galaxy Nexus but it hat the same screen size).
This is Verizon Telecom (eg FiOS) not Verizon Wireless. (Though they will soon be one in the same). The FCC only regulated wireline ISPs in it's Open Internet Rules. Thus Verizon Wireless can play all the games they want and sell their paying customers to content providers at will.
However, the case that went to federal court this week was brought by Verizon Telecom so that they could charge Netflix, YouTube, et al.. And they don't even need to degrade service, they just need to drag their feet on peering agreements.
What they are doing is purely evil. It's hostile to their own customers and they are already causing these problems. Now they are suing to be allowed to make it worse.
He didn't say anything about how Apple supports their devices, just that manufacturers and carriers want to sell devices as much as Apple does. He then notes that but they want to do it without having to upgrade the older ones. I think you're being a bit defensive there bud. The only misconception of reality here is in what you think he said. Apple's support of older devices is great. Google's is getting much better, especially given the logistical challenges of Android. (This is the whole point of the article). It's other manufacturers and carriers that are terrible.
I do think there were some bugs to be worked out because they patched the app signature stuff, but the reality is that those ROMs are not getting Google Play from Google, nor do they officially support them.
Incidentally, on any given day any quick check of XDA will show ROMs with a wide variety of bugs. Many of the ROMs on XDA are put together by hobbists who have figured out how to build AOSP from source. Many are quite talented and experienced but do not have a staff of QA testers, nor the inside knowledge of closed source driver APIs. So many bugs on custom ROMs revolve around the hardware driver issue. The hardware driver stuff is the bigger concern (IMHO)
Granted, it would be nice for customers to have an official way to obtain Google Play (as they do for many other gapps)
This is not a good idea, you'll end up breaking a lot of apps if you do this. Disabling Google Services would also disable the ability for 3rd party apps to make use of the many, many APIs it contains (where are very useful for app devs).
FTA:
Right now Play Services handles the Google Maps API, Google Account syncing, remote wipe, push messages, the Play Games back end, and many other duties. If you ever question the power of Google Play Services, try disabling it. Nearly every Google App on your device will break.
I'm not sure the Firefox OS brand carries much weight to keep OEMs and carriers in line. Google has the Play store, Gmail, Maps, Calendar, Drive, Music, Books, Google Voice, etc. They use these things as leverage to keep the OHA in line and compatible. And it's still a problem -- particularly from carriers (who think they hold the keys to the kingdom). I highly doubt carriers & OEMs will stop their dirty tricks for a new and relatively powerless brand name. Firefox is well known for the browser, but few people have yet heard of the OS/phone outside of tech enthusiasts. Even Google's leverage was not enough to stop Amazon from forking Android. What chance does Mozilla have vs Verizon or AT&T?
That said, competing forks might not be a bad thing per se... I think the next few years will be interesting times in mobile.
That's actually a marketing trick of a kind of "false choice". I can't remember where I read this but they have done studies involving this and the example was given with newspapers. Basically the idea goes, if they offer 2-3 choices and 1 is very expensive, another very cheap but the third makes it seem like you are getting the expensive plan for less, you think it's a deal in your mind. No one is immune to this, so I'm not singling out you, we've all felt victim to this as it's the natural way our brain makes order.
Not more, but not necessarily less. With a self signed cert, you cant verify the identity of the signer/cert. With the possibility of a compromised CA, you have (essentially) the same problem. (As far as understand it anyways).
What I would like to know is what (if anything) can be done to verify keys without a CA? I don't know that much about crypto, so am genuinely curious. Are there techniques to do this? (Diffie-Hellman-Merkle?)
ActionBarSherlock fills this role pretty well already, even with some added features. But this is good stuff nonetheless. The support library has always been a great addition to the SDK. It really helps avoid writing ugly wrapper classes, or the really ugly old technique of using reflection for API levels. I would like to see them add more widgets though. Such as TimePicker, CalenderPicker, etc. Some support for ORM, and better handling of Fragments, instance states, data persistence and Loaders (less black box-y).
Still it is nice to see the support library progress march on.
These sound helpful too:
Media - Added TransportMediator helper class to manage media transport control, such as play, pause, skip and other media actions. -Added DisplayManagerCompat for managing display output to one or more device displays.
Other changes -Added WakefulBroadcastReceiver helper class for implementing a common pattern of detecting a device wakeup event and passing work off to a Service while ensuring that the device does not go back to sleep before the handoff is complete. -Added two new APIs, commitContentChanged() and rollbackContentChanged(), to AsyncTaskLoader to help deal with background updates for data changes that are subsequently canceled.
Slashdot Mirror
Right, but have you gone into the game after changing IPs? Do you have a static/semi-static IP? Or dynamic?
Doesn't much matter *when* you are online --I'm saying as soon as you do go online it could be possible that if some component of the game, or even game/store client (I don't know if Steam or Origin do this) creates P2P connections. After changing IPs, as soon as that game/game client creates a new P2P connection, it's possible the attacker then knows your new IP.
Again, all depends on the game/client and I dont know which ones use P2P style networking to connect users.
It's also possible, though maybe less likely that if the game they are playing creates P2P connections between the players for say chat, then they could be revealing their IP that way. Like Freshly Exhumed said above though, it all just guesses without some evidence.
But what do I know, I'm a packet who got lost on his way to 127.0.0.1
It seems Google Apps accounts are opted out by default, but Gmail and other regular Google accounts may be opted in by default.
Still, they have made it very clear how to turn it off, and you would still need to comment, +1, or follow something for "Sharing" to kick in. I can kinda see how it's a nuisance, but they are being very up-front about it and making sure all user are notified via several notification methods.
I'm more bothered by the half-assed attempt to tie my Google account and real name to things like YouTube. Those prompts are (still) down right infuriating (and buggy, a few times I thought it might have change my YouTube account name).
This however, is hardly a blip for me. (Although to be fair, I use an Apps account).
Call you...? I see what you did there.
Video call?
You might look at a Moto X -- nearly the same performance in a smaller form factor. (Smaller than the Nexus 4, and Galaxy Nexus but it hat the same screen size).
but the only way to insure that would be
... to log on to website and buy insurance :)
Speedpass? Wow that seems invasive. Not sure how I feel about iPhone fingerprinting, but for a Speedpass that seems excessive.
Depends on how intensive your purposes are. :)
This is Verizon Telecom (eg FiOS) not Verizon Wireless. (Though they will soon be one in the same). The FCC only regulated wireline ISPs in it's Open Internet Rules. Thus Verizon Wireless can play all the games they want and sell their paying customers to content providers at will.
However, the case that went to federal court this week was brought by Verizon Telecom so that they could charge Netflix, YouTube, et al.. And they don't even need to degrade service, they just need to drag their feet on peering agreements.
What they are doing is purely evil. It's hostile to their own customers and they are already causing these problems. Now they are suing to be allowed to make it worse.
Another good read:
http://arstechnica.com/tech-policy/2013/09/fccs-wishy-washy-rulemaking-might-doom-net-neutrality-in-court/
The biggest one is Maps the v2 (Android) Google Maps API is part of Google Play services. (What 3rd party devs use).
Anyways, there is a picture in TFA that covers the Google services & apps you would lose without Google Play Services (i.e. almost all of them).
I think you would also lose any games/paid apps that use the Play store licensing (LVL).
He didn't say anything about how Apple supports their devices, just that manufacturers and carriers want to sell devices as much as Apple does. He then notes that but they want to do it without having to upgrade the older ones. I think you're being a bit defensive there bud. The only misconception of reality here is in what you think he said. Apple's support of older devices is great. Google's is getting much better, especially given the logistical challenges of Android. (This is the whole point of the article). It's other manufacturers and carriers that are terrible.
I do think there were some bugs to be worked out because they patched the app signature stuff, but the reality is that those ROMs are not getting Google Play from Google, nor do they officially support them.
http://wiki.cyanogenmod.org/w/Gapps
Incidentally, on any given day any quick check of XDA will show ROMs with a wide variety of bugs. Many of the ROMs on XDA are put together by hobbists who have figured out how to build AOSP from source. Many are quite talented and experienced but do not have a staff of QA testers, nor the inside knowledge of closed source driver APIs. So many bugs on custom ROMs revolve around the hardware driver issue. The hardware driver stuff is the bigger concern (IMHO)
Granted, it would be nice for customers to have an official way to obtain Google Play (as they do for many other gapps)
This is not a good idea, you'll end up breaking a lot of apps if you do this. Disabling Google Services would also disable the ability for 3rd party apps to make use of the many, many APIs it contains (where are very useful for app devs).
FTA:
Right now Play Services handles the Google Maps API, Google Account syncing, remote wipe, push messages, the Play Games back end, and many other duties. If you ever question the power of Google Play Services, try disabling it. Nearly every Google App on your device will break.
Gingerbread phones run Google Play Services* pretty well.
That's kind of the point, they can push out updates to say the Maps API and let devs use those APIs on older phones.
Seems to be rumors for both.
Honestly I think I'd prefer moto, but I will be looking forward to it either way as long as it is not a "phablet"
http://www.ibtimes.com/nexus-5-release-date-coming-latest-rumors-suggest-motorola-manufacturing-lg-still-possibility
(granted, take anything IBT says with a whole lot of salt)
I'm not sure the Firefox OS brand carries much weight to keep OEMs and carriers in line. Google has the Play store, Gmail, Maps, Calendar, Drive, Music, Books, Google Voice, etc. They use these things as leverage to keep the OHA in line and compatible. And it's still a problem -- particularly from carriers (who think they hold the keys to the kingdom). I highly doubt carriers & OEMs will stop their dirty tricks for a new and relatively powerless brand name. Firefox is well known for the browser, but few people have yet heard of the OS/phone outside of tech enthusiasts. Even Google's leverage was not enough to stop Amazon from forking Android. What chance does Mozilla have vs Verizon or AT&T?
That said, competing forks might not be a bad thing per se... I think the next few years will be interesting times in mobile.
How do I mod +1 Redundant?
Me either :) But the good tech review sites have them (Anandtech, for example)
Also brightness should be measured in absolute terms (nits). One tablet's 50% is not the same as another.
Edit: the guy was not from the Economist, but it was used as an example.
That's actually a marketing trick of a kind of "false choice". I can't remember where I read this but they have done studies involving this and the example was given with newspapers. Basically the idea goes, if they offer 2-3 choices and 1 is very expensive, another very cheap but the third makes it seem like you are getting the expensive plan for less, you think it's a deal in your mind. No one is immune to this, so I'm not singling out you, we've all felt victim to this as it's the natural way our brain makes order.
Ah here it is, it was someone from the Economist:
http://danariely.com/the-books/excerpted-from-chapter-1-%E2%80%93-the-truth-about-relativity-2/
TED video:
http://www.youtube.com/watch?v=xOhb4LwAaJk
Ah ok, thanks :)
This is a decent code sample too:
https://code.google.com/p/adamkoch/source/browse/#git%2Fbitmapfun
From, here:
http://developer.android.com/training/displaying-bitmaps/index.html
(adam koch is an Android developer advocate at Google, and the code comes from the AOSP but is backported to use the support lib)
Not more, but not necessarily less. With a self signed cert, you cant verify the identity of the signer/cert. With the possibility of a compromised CA, you have (essentially) the same problem. (As far as understand it anyways).
What I would like to know is what (if anything) can be done to verify keys without a CA? I don't know that much about crypto, so am genuinely curious. Are there techniques to do this? (Diffie-Hellman-Merkle?)
ActionBarSherlock fills this role pretty well already, even with some added features. But this is good stuff nonetheless. The support library has always been a great addition to the SDK. It really helps avoid writing ugly wrapper classes, or the really ugly old technique of using reflection for API levels. I would like to see them add more widgets though. Such as TimePicker, CalenderPicker, etc. Some support for ORM, and better handling of Fragments, instance states, data persistence and Loaders (less black box-y).
Still it is nice to see the support library progress march on.
These sound helpful too:
Media
- Added TransportMediator helper class to manage media transport control, such as play, pause, skip and other media actions.
-Added DisplayManagerCompat for managing display output to one or more device displays.
Other changes
-Added WakefulBroadcastReceiver helper class for implementing a common pattern of detecting a device wakeup event and passing work off to a Service while ensuring that the device does not go back to sleep before the handoff is complete.
-Added two new APIs, commitContentChanged() and rollbackContentChanged(), to AsyncTaskLoader to help deal with background updates for data changes that are subsequently canceled.
http://developer.android.com/tools/support-library/index.html