Spokesmen for each campaign have separately said that their own campaign had put safeguards in place to protect that user data, as Charles Duhigg and I reported in an article published in The New York Times on Oct. 28.
But now a new study by Jonathan Mayer, a graduate student in computer science and law at Stanford University, reports that both sites are leaking information about site visitors to a number of third-party trackers operating on their pages.
Christian Cantrell (via Rich Siegel):
Being the determined hacker that I am, I initially saved the source from the confirmation page, fixed the error by turning “ ” into “&nbsp” (the character code for ampersand followed by “nbsp” — the proper way to escape user input in this case), and started working on tricking the DMV’s servers into believing that the form I was submitting actually came from them. But then it occurred to me that I could simply fix the DMV’s mistake using the WebKit Web Inspector. I opened up the awesome Chrome Dev Tools, made the change in the live page, and the form submitted perfectly. About two weeks later, my brand new plates arrived.
The adapter works well when it works, providing full FireWire 800 performance. But users of the adapter have encountered a frustrating limitation: Only 7 watts of bus power is supplied to an attached device. The FireWire standard supports up to 45 watts, although most computers, including Macs, deliver 10 to 20 watts. Some bus-powered FireWire devices have an optional DC power port, even if they don’t include an AC power adapter. If you can externally power your device, you can bypass the 7-watt limitation. Otherwise you’ll need to explore other solutions.
Unfortunately, this transition seems to be taking a while. FireWire is on the way out. Thunderbolt devices are few and expensive. USB 3 is here and fast. It’s great in theory, but USB has never approached the reliability of FireWire.
What frustrates me about setting constraints with Interface Builder is its instance on adding more constraints automatically for me, even if I don’t want/need them.
[…]
When something has such a steep learning curve as Auto Layout, you want to provide as much documentation and help as possible, especially if you want developers to adopt the technology.
In the case of Auto Layout, the best documentation isn’t in Apple’s official documentation. It isn’t in a book. It’s in three hours of WWDC 2012 videos.
Auto Layout debuted with Lion, so you would think there would have been time to fill out the documentation. Still, I’m excited to start using it in my apps.
If you click on your purchases it’ll frequently claim that several of them belong to an other account, even though I’ve only ever used a single account. Thus they don’t update properly. So I can’t get tonight’s iPhoto update, for instance.
I’ve seen all sorts of weird behavior with the Updates tab. Yesterday, a customer reported that it was offering EagleFiler 1.5.10 as an update. This was the version he already had installed, and although it was listed as an update the button was disabled. To prevent the Mac App Store from offering this “update” he had to delete and reinstall the app.
I wanted to use bindings, so that the UI will always update as new objects are created. The problem is, I couldn’t bind to my Core Data entities, because the NSTreeController expects just one kind of object throughout its tree. Also, my groups and my static rows aren’t in the database.
I’m not convinced that it makes sense to use Cocoa bindings in this situation, but if you want to do so she explains the non-obvious way that you can make it work.
