3 ms·

Isn't this the Like/+1 case where Mobile Safari settings disabled actually useful internet behavior (that is, Broke the Web for federated login services), and s

Isn't this the Like/+1 case where Mobile Safari settings disabled actually useful internet behavior (that is, Broke the Web for federated login services), and so Google, Facebook, and app developers with federated login needs devised a workaround by exploiting Safari behavior? IIRC, the workaround however 'leaked' due to a browser bug (which Google themselves submitted a fix to WebKit for) which causes other cookies to bypass the filter. Google also stopped doing it, and removed all the cookies that had been set. So what do the people pushing this suit want to happen? The loophole got closed (IIRC, the webkit fix by Google happened prior to the WSJ story exposing the loophole, it's just that Apple doesn't update its browser that frequently), the cookies were removed, the behavior has stopped. There is still the need for federated, secure, login, whether it is cookies or some other mechanism, it is a problem that has to be solved, I worry government interference can actually inhibit progress here. And why isn't Apple included in the case? Shouldn't they be suing for a faulty implementation as well? If someone sells a door lock that doesn't really work, and your house gets robbed, the robber gets charged, but you can bring a civil case against the lock manufacturer too. After all, even if Google's behavior is changed, there are lots of other blackhats who can leverage bugs, so going after a single exploit isn't actually solving the problem, the single point of failure was the Safari implementation. <conspiracy theory time> I'm somewhat skeptical that this is an organic case. I mean, I do think people have a right to have their day in court if they think they were actually harmed by this, but could it be that Microsoft's byzantine array of "attack Google" organizations is behind this case? I have a nagging suspicion.

jacques_chester 13y ago
The EULA of Safari specifically disclaims warranties and fitness-for-purpose to the limits of law (section 7). Further, it would be pretty hard to get damages when no money has changed hands and actual economic loss is basically impossible to calculate. Meanwhile, the presence of the door lock, even if faulty, clearly signals your intention that nobody enter without permission. Even a rope across a driveway can signal an unwillingness to receive visitors; anyone who gets past it is a trespasser, committing a civil wrong and probably a crime. That's roughly analogous to Google's position: sure the mechanism had a bug. But the intention of the mechanism is pretty obvious and arguing that unless a lock is perfect you can do as you please with other people's property isn't going to be a very scalable law. TINLA, IANAL.
- cromwellian 13y ago
  But I don't think the intent of the lock in this case is to make federated services impossible to use properly. Clearly, the purpose of the lock in this case was to prevent third party tracking cookies. The problem is, there's no technological way to segment cookies used for authentication from cookies used for tracking in this way. The Web has an authentication problem. Existing solutions have tried to work around it by leveraging browser features not originally designed for the purpose. The result is privacy snafus like this. Google, Facebook, et al, would argue that they have platforms, and networks of sites, with a real need for this functionality, whose basic goal is not to invade privacy, but to improve enduser UX when using their services.
  - jacques_chester 13y ago
    That it is inconvenient not to abuse a bug is not an argument in its favour. It might be inconvenient not to trespass. Too bad, it's still trespass. I agree with the problem of authentication; I actually have a patent application in covering a solution to a tangential authentication problem. I tried for several years to do it all with cookies and javascript; my eventual conclusion was that it can't really be done securely. So the generalised design I submitted depends on piggybacking on extensible command channels -- HTTP headers, in this particular case.

jacques_chester 13y ago

The EULA of Safari specifically disclaims warranties and fitness-for-purpose to the limits of law (section 7). Further, it would be pretty hard to get damages when no money has changed hands and actual economic loss is basically impossible to calculate. Meanwhile, the presence of the door lock, even if faulty, clearly signals your intention that nobody enter without permission. Even a rope across a driveway can signal an unwillingness to receive visitors; anyone who gets past it is a trespasser, committing a civil wrong and probably a crime. That's roughly analogous to Google's position: sure the mechanism had a bug. But the intention of the mechanism is pretty obvious and arguing that unless a lock is perfect you can do as you please with other people's property isn't going to be a very scalable law. TINLA, IANAL.

cromwellian 13y ago
But I don't think the intent of the lock in this case is to make federated services impossible to use properly. Clearly, the purpose of the lock in this case was to prevent third party tracking cookies. The problem is, there's no technological way to segment cookies used for authentication from cookies used for tracking in this way. The Web has an authentication problem. Existing solutions have tried to work around it by leveraging browser features not originally designed for the purpose. The result is privacy snafus like this. Google, Facebook, et al, would argue that they have platforms, and networks of sites, with a real need for this functionality, whose basic goal is not to invade privacy, but to improve enduser UX when using their services.
- jacques_chester 13y ago
  That it is inconvenient not to abuse a bug is not an argument in its favour. It might be inconvenient not to trespass. Too bad, it's still trespass. I agree with the problem of authentication; I actually have a patent application in covering a solution to a tangential authentication problem. I tried for several years to do it all with cookies and javascript; my eventual conclusion was that it can't really be done securely. So the generalised design I submitted depends on piggybacking on extensible command channels -- HTTP headers, in this particular case.