Slashdot Mirror

The standard for HTML was developed as a way for scientists to communicate with each other, and against a background of Usenet norms which were hostile to advertising. I don't think it's really fair to blame Berners Lee for failing to foresee what the WWW would become.

Berners is not to blame --agreed! However, there is no real power to prevent the current WWW committees and browser implementors from doing stupid things (feels like the sinking ship that was the adoption of KDE 4.0, Gnome Shell, Windows 10). Power Users Who Care are facing a losing fight. Most can't just fork Firefox every time it drops a feature nor expect Palemoon and Waterfox to support it forever, or at all. At some point an annoying standard is introduced that will not be reflected by these forks I do follow, or the browser just makes one up despite the obvious ill-will.*

We the users should be making the W3C and browser implementors responsible for crap standards and policy decisions. "Just switch!" isn't working when the 4 major browsers are an illusion of choice. It's almost like 2-party political voting, or broadband's "vote-with your wallet", or using iOS to run Safari skins that are marketed as non-Safari browsers.

* W3C was OK with a standard "Battery Status API" that eventually got canned for allowing mobile device fingerprinting - https://blog.lukaszolejnik.com...
There has been some stuff that seems to favor advertisers rather than regular folks (tracking beacons, localstorage tracking) are more often than not used by the enemy than corner cases of the likes of Flash games.

Good investigation of the current API here: https://blog.lukaszolejnik.com...

TL;DR there are some major privacy problems with it, but bug reports have been filed so hopefully they will be fixed.

Maybe not... https://blog.lukaszolejnik.com...

Aside from TfL's apparent confusion of various technical terms, it looks likely that the salts could be recovered. MAC addresses are not random, they are assigned in blocks to manufacturers. Some devices do randomize them, but some don't and it appears that they use only one salt per day for every MAC address they hash.

You can assume that there will be a large number of devices running wifi chipset X and not randomizing. That gives you a way to check a salt for validity, i.e. if when combined with known MAC addresses from the ranges allocated to that manufacturer it produces a hash in the TfL dataset. And you can further narrow this down by taking your own device with a known MAC address onto the tube during the test.

It's probably fine... But their lack of technical clarity and secrecy about the scheme they used (for all we know the salts could have just been the date or something silly) isn't very encouraging. As a branch of government they should set the gold standard for this stuff.