Showing posts with label self repairing. Show all posts
Showing posts with label self repairing. Show all posts

Monday, January 3, 2011

Verizon iPhone pretty definite in 2011; another iPhone alarm fail

iPhone on Verizon soon

If reports on Pocketnow.com are drawing the correct conclusions Apple should be announcing a Verizon iPhone soon. Apparently there are accessories availble for Verizon iPhones, and Verizon is buying iPhone related domains like "iPhoneVerizon.com" among others. Apple exclusive contract with AT&T ended in 2010, so there's nothing to keep Apple from making deals with other carriers - and if they want tocontinue to grow and remain a power in the smartphone market, they need other carriers. So there will probably be an announcement in January with phones available March or April. Or they may make a low end iPhone available immediately with higher end phones later. They may make high and low end available immediately, it's just not the way Apple usually does these things.

Another iPhone Alarm fail

It's over now, but for the first two days of January 2011 if you set a one time alarm on your iPhone it wouldn't go off. No word on what caused the problem, only that it would fix itself January 3rd. So if you missed something important because the alarm you set in your iPhone didn't go off, it won't happen again. Really.

Friday, September 24, 2010

Enter the evercookie

Security researcher Samy Kamkar has created what he calls "evercookies" and others are calling "frankencookies." I could add, "zombiecookies." Like Frankensteins monster, they are created from 10 different types of data storing objects. Like zombies, unless you completely eradicate all of it's components, the evercookie will return. 


On Samy's evercookie page he gives some details, along with a demonstration and two different links to download the source code. Among the details he gives are the types of storage objects used to retain and resurrect the data:


Specifically, when creating a new cookie, it uses the
following storage mechanisms when available:
  • Standard HTTP Cookies
  • Local Shared Objects (Flash Cookies)
  • Storing cookies in RGB values of auto-generated, force-cached
    PNGs using HTML5 Canvas tag to read pixels (cookies) back out
  • Storing cookies in and reading out Web History
  • Storing cookies in HTTP ETags
  • Internet Explorer userData storage
  • HTML5 Session Storage
  • HTML5 Local Storage
  • HTML5 Global Storage
  • HTML5 Database Storage via SQLite

Samy provides a demonstration that produces supposedly non-traceable evercookies, cookies with just enough information to prove the cookies have been created. He notes that private browsing in Safari defeats evercookies. I tested Firefox and it also killed evercookies in private browsing mode. Both only kill evercookies if you are already in private browsing mode when you the cookies are placed. Safari's reset option will not kill an evercookie.

Evercookies are a heinous development - from a privacy point of view. To merchants and ad services they are a gift from the Internet gods. Before we have a good answer to Flash cookies, evercookies appear, making Flash cookies look positively ephemeral. Because they are comprised of several different files of several different types in multiple locations they are hard to find, and if any piece of an evercookie is left behind the entire cookie can be recreated. If it wasn't already bad enough, Samy is seeking more ways to make evercookies hard to find and kill.

Privacy is in large part control of information. The more control you have over your information, the more privacy you have. The more others control your information, the less privacy you have. Things like Flash cookies and evercookies remove control of your information from you and give it to others and are designed to make it hard for you to get rid of them. That is enough reason for me to dislike them.