Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Friday August 14 2015, @12:09PM   Printer-friendly
from the overcharged-reaction dept.

IT’s relationship with privacy is delicate. Corporate IT needs to take privacy fears very seriously, but if IT jumps and shouts at every tiny possible privacy invasion, we’ll have the Bot That Cried Wolf. Put another way, the best way to weaken privacy protections is to embrace so many privacy problems that none have any significance.

Am I suggesting that manufactured privacy issues are obscuring real ones? Absolutely. For proof, one needs look no further than last week’s battery brouhaha from a report that noted that websites can track people based on their batteries, skirting opt-in privacy rules that allow battery strength reports to be shared without site visitor permission. For those who bother to read the full report, its details do a wonderful job of establishing that if a site manager wants to invade someone’s privacy, that manager could do far better than peeking at energy levels.

The researchers’ argument is that battery levels — both current power levels and battery capacity — are being reported so precisely that it would function as a poor admin’s cookie, albeit an unerasable cookie. The problem is that, in this situation, precision cuts both ways. A tracking system needs to have a static element, so that the user can be recognized the next time the user shows up, even anonymously. But given that battery levels change constantly, it will often not work. The researchers counter that this could be useful in a very short time frame. Possibly, but even so, it would sharply limit how valuable a tracking mechanism it is.

More after the break.

Also, this tactic does not consistently work, the researchers found, across all operating systems nor for all browsers. I tend to worry about privacy threats. On this one, I feel positively Zen-like.

How precise did those readings prove to be? In one instance, bizarrely precise. “In our exploratory survey of the Battery Status API implementations, we observed that the battery level reported by the Firefox browser on GNU/Linux was presented to Web scripts with double precision. An example battery level value observed in our study was 0:9301929625425652,” the report said, adding that such ludicrous precision was not the norm: “We found that on Windows, Mac OS X and Android, the battery level reported by Firefox has just two significant digits.” 

To be clear, there is almost no room here for extrapolating patterns and projecting where a particular user’s numbers will be, for example, an hour from now. Is the user plugged into a wall outlet or a different source of consistent power? Will the user turn off Wi-Fi and shut down the machine — or stream an hour of video?

The report says, for example, “we can also assume that users seeing a near-drained battery generally connect their notebooks to AC power.” First, having a phone or laptop battery that is nearly drained is not the same as having a user notice it. Who is to say what “nearly-drained” is? Just as different car drivers interpret an “almost-empty tank” differently — I drive my wife crazy because I don’t consider getting gas to be urgent until the empty tank light has been on for at least 10 miles, whereas she considers it mandatory at one-quarter full — so do people react to low batteries differently. 

Also, is the user perhaps in a crowded airport or in a car or somewhere else where plugging in is not practical? 

But can it be used to identify site visitors in a very short time frame? The time frame suggested in the report was 30 seconds. How many site visitors do you guess your site has who visit, leave and then return 30 seconds later? How valuable is a technique that will positively identify only a small percentage of those visitors?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Friday August 14 2015, @12:39PM

    by Anonymous Coward on Friday August 14 2015, @12:39PM (#222794)

    Browsers are already hopelessly stupid even still on mobile devices, especially in how most sites work with them.

    The entire experience of using a web browser is still based on the idea of using a desktop PC. Fill in a form and you get a 15 minute window before your session times out. Session? I'm on a persistently online device which is always with me, my session should last 24/7. I will fill it in over the course of 3 hours in my pocket. Too bad this will never be feasible with the total lack of legitimate security measures on nearly every consumer device and account. But it gives an idea of what the experience could be like. At such a time I might imagine battery life being slightly useful to the browser because it interrupts this mobile-driven paradigm.

  • (Score: 0) by Anonymous Coward on Friday August 14 2015, @01:12PM

    by Anonymous Coward on Friday August 14 2015, @01:12PM (#222804)

    The entire experience of using a web browser is still based on the idea of using a desktop PC. Fill in a form and you get a 15 minute window before your session times out. Session?

    Not a concept of the original web. HTTP is designed as stateless protocol. The concept of a session is completely alien to HTTP.

    And here, it's not the browser that's at fault, it's the server, or rather the web app. The web app defines a session and sends the browser a cookie (or other session identifier) together with the web page containing the form. The browser just dutifully sends all the data you entered, and any associated data the server defined, to the server. It's the server that then looks at the session token, identifies it to be of a session it considers expired, and refuses to further process the data.

    So put the blame where the blame belongs, and in the case of expired sessions, it's not the browser.

  • (Score: 2) by c0lo on Friday August 14 2015, @02:17PM

    by c0lo (156) Subscriber Badge on Friday August 14 2015, @02:17PM (#222830) Journal

    I'm on a persistently online device which is always with me, my session should last 24/7

    Session expiry was never about the client capacity to keep on going, otherwise we wouldn't see session expire when connected from a desktop.

    It is about resources the server-side reserves for the session: do you really want to ask the poor govt agency (that offers the online form) to spend tax money on infrastructure like gmail?
    Gotta ask yourself how could NSA could keep up those interception centres if all the tax money would go to provide 24/7 services to citizens?

    --
    https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford