In that case, it'd be simple enough to snip the wires to the transducers and take the analog signal from there. Even if there is wonky EQ for the specific transducers in use, it'd be simple enough to do a frequency sweep to figure out the filtering needed to undo it.
I respect and appreciate the hacker spirit that lets us understand that we can always work around things like DRM, but I'd prefer to fight it up front rather than deal with it later. There's MILLIONS of devices that currently work with 3.5mm stereo jacks around the world. Just because we can bypass the DRM in some way, it is unfair to the population at large to make this change when it incurs no real benefit just to satisfy the DRM desires of content producers.
In order to do that, you first have to buy a pair of the (likely expensive) DRM-enabled headphones, then destroy them and solder to the annoyingly hard-to-solder wires inside. Ultimately, this isn't going to stop piracy so much as it is people buying headphones that Intel haven't approved and charged a per-unit licensing fee on - it's about making sure they get their cut. It's probably a win-win for Intel and the headphone manufacturers too; Intel get to take a cut and the headphone manufacturers get to charge a premium to consumers, safe from competition from $3 earbuds from China (which are actually pretty good these days).
Until that is made illegal and you go to jail because you modified your device with the intention to circumvent content protections you agreed with when you bought the device.
It's not about the security of the cookies, it's about the bandwidth you save by having a separate domain for static content, because the client does not have to transmit the cookies for each request.
If you issue cookies to www.example.com your browser will not send them to cdn.example.com unless it's very poorly written.
Each cookie has a path set to it and browsers will obey it, this includes inter-domain paths and restrictions.
If you want you can go even further and assign a cookie to a specific URI path so the cookie will only be issues to pages that fall under www.example.com/private/ for example if that's what the path is set too.
There are many high profile websites that use the cookieless domain approach: Google, Facebook, and Reddit off the top of my head. I wouldn't say they are poorly written - it's more of a design decision to have cookies in the top-level domain.
I didn't say the sites would be poorly written, the browsers would be if they do not obey the cookie set domain and set path restrictions.
And the fact that big sites use it doesn't mean that they were "well written", Google mostly issues only tracking cookies for wildcard domains like .google.com as far as private cookies go they usually would be issued for each domain individually (play.google.com etc.).
Issuing authentication cookies to wildcard domains and root paths isn't advisable even if some big sites do it doesn't mean you should take it as an example :)
P.S.
I really hate "Google and Facebook are doing it" as an example, even if they are you most likely aren't either of them, not even close they have quite different considerations than you.
Even when they do things which aren't best practice or common sense it doesn't mean that you should decide to take the same path, both Google and Facebook have plethora of ways to ensure account security including quite decent activity heuristics, they have many ways of detecting attacks such as XSS, and they have most likely a much better process of ensuring that vulnerable pages do not go live or do so quite rarely.
Unless you can say the same then do not use them as an excuse, you do not need to issue cookies to wildcard domains and you can restrict them to certain paths, and you better do so because you do not have many other mitigating controls in place as the big players do.
Ah, sorry, I misread your comment. Indeed, a browser that doesn't respect cross-domain restrictions is a poorly written browser.
My point still stands, though: the point of cookieless domains is not security, but bandwidth. And there are legitimate reasons to have top-level domain cookies - sharing authentication state between subdomains is a common example - which would prevent a subdomain from being used as a CDN, without receiving cookies.
Because WhatsApp uses your phone book as the only way to interact with its contact list. You can't add someone to directly to your WhatsApp contact list.
It could probably access it less often by only sending deltas, but that would mean their servers would have to store your whole phone book. I don't think that's any better from a privacy perspective.
Of course Facebook Messenger doesn't do the same, it has its own contact list coming from Facebook.
Yeah, but roughly every 30 seconds is a bit too much to access... it's one thing to do so while actively using the application... it's another to run these queries all the time, and that is simply ridiculous.
Pure speculation. How do you know? It could be just as well that Whatsapp queries contacts one by one at the moment they are supposed to show up on the screen.
That way you could easily have 150 times (depending on the size of your contact list) your database accessed by scrolling once through your complete contact list.
Or the author is one of the few that has 1k contacts. In this case basically any operation that requires querying every single contact every now and then could cause this.
Also: the thumbnails you see of your contacts are accessed via URIs - could be that Android increases the counter every time you show a thumbnail of a contact. (it is part of your contacts information)
Wouldn't even call it a programmer error. Someone probably just implemented a getContacts() function that gets called often in the background without saving the data in a local database or caching - and why would you do anything other than this for very marginal performance benefits, a rise in complexity, and possible data sync issues?
Another app might access your contacts rarely but store them on their server (Facebook!?). I definitely prefer the previous scenario.
Plus, I would imagine that the contacts list is going to be the most efficient way to store and retrieve that data. It's in a database, just like anyone else's is, right?
Not to snark, but how do you know this? Do you know what actions increment the "This app accessed the contacts list" counter, and how many of those actions a comparable IM/telephony app executes? :)
> replacing the powerful bulb with an under powered LED.
I've also seen that Sony and Epson are selling laser illuminated projectors as opposed to the more common LED/halogen/etc illuminated projectors. Apparently for high luminosity, laser becomes more efficient and less prone to damage than both LED, halogen, incandescent, argon/xenon etc.
But it disappoints me that these projectors just use the laser for illumination. I'm waiting for when we have laser-on-DLP without filters type projectors.
I thought they had been doing this for a while too, the location indicator is usually active in iOS, even when Foursquare is not running. Go into location privacy and it shows Foursquare as the one getting location.
The weird thing it seems they just started doing is displaying places it thinks you've been recently, along with all your past check-ins. It's not particularly accurate either.
On iOS this isn't necessarily true under certain constraints.
They can make it impossible given the device is not jailbroken. Sometimes there are versions of iOS that are un-jailbreakable. If you are not Apple, it could very well be impossible to figure out what an app is sending to a remote service if it gets its cryptography right.
Edit: thinking about it, although it may be impossible to MITM the connection, presumably one can inspect the compiled application to determine what it would send, so I think I was wrong about this
Apple doesn't have the best track record around auditing software for obfuscated functionality. The OS is built around the assumption that an app can misbehave without risking the user's resources. Of course, jailbreaking disproves this.
Thank you for the feedback. That was my original intention, but seeing the constant location updates from Foursquare while writing the article surprised me (admittedly not too much).
While recently digging into CoreLocation's CLLocationManager recently I also discovered that any app which is given location privileges can be saving your location every 10 min in the background. It was a surprise to me too.
This, along with the M7 motion co-processor in the new iPhone 5S, and Apple's pretty substantial investment in iBeacons, tells me that Apple sees the future of the iOS ecosystem as a series of experience-enhancing physically-aware ambient apps.
(The kind of apps that require a good notification center - like the one in iOS7 - cuz they're spewing so many little bits of suggestions at you.)
I suspect Apple will tread carefully in these waters, but initial signs are worrisome. Let's hope that they can figure out the personal analytics thing and work in some privacy with it too. They're not an ad company, so it's possible. :)
