Zipcode plus address is usually plenty though. And it's certainly good enough to obviate the tedious selection of the state from a 52-item dropdown menu.
OSX doesn't use IP geolocation to determine location... they use wifi triangulation. VPN connection-state shouldn't make a difference one way or another.
You're correct in pointing out that the odds of #FF4A00 being selected randomly are the same as the odds of #EAF7C2 being selected randomly; just as the odds of the Powerball numbers 1 2 3 4 5 P6 being selected randomly are just the same as the odds of the Powerball numbers 1 36 40 52 53 P20 being selected randomly. However, the odds of the former sets being selected non-randomly are greater.
You and I see a single site where you can go and find movies people have uploaded to YouTube. The MPAA sees a single site where they can go and make their DMCA requests to YouTube. I question how long this will be useful.
Also, it's up to individual rightsholders to submit DMCA requests not the MPAA (as far as my experience goes). If you look into how fragmented rights ownership is in the film industry, you'll soon realise how unlikely it is that the site dies because of DMCA requests.
Yes, but the sword cuts both ways. You wouldn't have been able to find these films either, so if the there's a DMCA takedown it ends up being a wash (for the vast majority). Sure you can have underground sharing sites, but that requires a much larger personal time commitment for an inferior selection. Worst case would be that MPAA uses the data and the site stops being useful so people stop submitting, so the damage it could cause to film sharing seems self-limiting. It seems a worthy experiment to me.
I like Android intents and all, but I think Facebook is misguided if their plan is to release a new version of Home every month. The intent preference is only remembered for the same version of the app... that means if they choose to update the version the user will be asked if they want to launch the intent with Facebook Home again ("Just Once" / "Always").
Facebook already knew this, that's one of the reasons why AT&T and HTC are included in this project, for HTC first device they will install it as system app which will avoid this problem.
Collaborating with HTC and AT&T allows them to install 'Home' as system app in future devices, this will allow their app to add 'layers' on top of any app. This can only be done if device is rooted or app is installed as system app.
You've got this problem (wether this behavior is an actual problem or a benefit to the user is open for debate) no matter what if you rely on being a default Intent in any way. What do you expect them to do, never update again?
That is accurate - SIP From Twilio is connect from Twilio to your SIP gear. We do not yet support SIP from your gear to Twilio.
After much consideration and talking with our customers, we decided to release our SIP features as it met our standard of quality rather than hold up release on bidirectional functionality.
I've had good experiences so far by keeping a dedicated browser for use with "legacy" services (such as school) that require Java. I haven't tried it, but I would suspect the profile manager in Firefox may help with that kind of setup, too.
First, it would be significantly more of a hassle to boot up a separate OS for the purpose of executing a short-lived task (such a submitting homework, or doing banking, as others have mentioned). Related to that, there is a slight disconnect between the host filesystem and the guest filesystem. The more convenience one has (e.g. greater transparency and sharing) the greater the risk.
Related, but separate from that: how would you know the VM was compromised and thus should be destroyed? One could presumably just periodically destroy (or revert to snapshot). Perhaps even if it was compromised, maybe the short lifespan of the VM would limit the damage to others.
Who needs to link to the current user's profile page without knowing it? Only FB should have to do that and they know the profile page url. Other people should be linking to the profile page directly only if they know it, not based on which user is viewing. They should really have two profile URLs:
To fix this FB could stop doing this redirect entirely as it leaks information about the current user's session, and should not be necessary. I'm sure it'll break someone's links, somewhere, but it was a bad idea to begin with, and related is this old trick which let's you view a very popular profile:
All that should be required is a public profile url which can be shared (if you wish) or not, and a private profile url, and the url of the private profile should be generic and not redirected, so that it doesn't leak info in this way, and because it's not the same as a public profile anyway.
The problem with that is that different people viewing the same URL (/profile.php) gets a different resource. What happens if someone gives a link to his profile.php over IM or something, expecting it to show his own profile? The URL the user is shown in the address bar should represent the current resource being viewed.
A better solution could be to replace links to profile.php with direct links to the real profile URL, and just kill that profile.php redirection.
see a different resource? For a web app like FB I don't think this avoidable. All data served is dependent on who you are when you are logged in.
For another example of how to handle this better, see twitter:
twitter.com - the user's feed, content differs for each user
twitter.com/username - the user's public url, for sharing, a proper URI which everyone can use
twitter.com/settings/profile - the user's private profile, content differs for each user
I agree they shouldn't need that redirection with no id supplied and I suspect it's just a legacy of the original way of showing profiles (profile.php?id=n), they could just redirect it to root instead (shows the same as profile.php it seems) to avoid leaking state.
It looks like this is just a prepaid credit card with dedicated balances for each merchant. While I'm sure Facebook has buy-in from the merchants (as they are using their logo and other brand marks), in theory Facebook could offer gift cards for arbitrary merchants. At POS Facebook just uses the merchant identifier to determine which balance to approve funds and subtract from -- aside from that, it works like a normal prepaid credit card.
It doesn't appear that this is the case. This is more like a multi-gift-card (not sure of any technical term for it) than a pre-paid credit card. From all I can see, you can't use it to make purchases at any merchants other than the ones which have balances on the card. This is much like the Verizon Visa Gift Card that was being given out when you would sign up for certain FIOS services. It was a Visa credit card, except it was not able to be used at any Visa accepting merchant, but only Verizon approved merchants. Hardly a normal pre-paid credit card.
That's my point... from the merchant standpoint there is no additional integration required... they just process it as a credit card. Facebook limits the spend based on the merchant identifier that gets sent to them from the POS. Basically they've created a multi-gift-card using existing credit card technology without the partners needing to update their POS to support it.
"Do you have a gift card or promotional code?" Y/N, and then only show the field if yes is selected.