Googles bullying / bribery won yet again.
In 2015, as part of a privacy review conducted under the auspices of the World Wide Web Consortium (W3C), Nick Doty flagged a potential problem with web applications. This week, after five years of debate about whether or how to mitigate this privacy concern, the technical types discussing the matter have simply given up and …
Is ‘Google’ the universal answer for the lazy of mind?
The doc/spec for the web app manifest was started by "Marcos Caceres, Mozilla Corporation" in 2013. Worked on in parallel since then with "Mounir Lamouri, Google Inc." and plenty of others. This isn't the first time a technology was made useful without considering security. Note the several commentatoreros saying they've turned off JS in browser.
Words for cheap like 'radical', 'leftist', 'extremist', "Google is tha eevihl!" are not the height of insight, nor informative.
Well, it's true.
Google's vote nixed the W3C privacy group after members rightly stated that Google's so-called "privacy sandbox" was a load of old nonsense. In Google's objection they gaslighted all a bit suggesting that with no "authoritarian" review body 1000 flowers can bloom, but they know Audrey II (Chrome) can come along and kill them all off.
Actually, it looks like the way to stop people being tracked is to have laws that effectively protect privacy.
In any communication, you need to identify the end points and it would be an extraordinary technical feat to prevent that necessary identification being exploited in any circumstance.
If you're concerned about evil, money-grubbing corporations, you can't really expect commerce to be the source of a technical solution.
The flaw in there assertion is, I think, that the SITE should be able to specify the Start URL. Allowing(which is to say forcing) the user to edit this is not a good solution, but they were on the right track with the OS/Browser mitigations.
Off the cuff let the SITE request the os or browser build the URL from a limited(and not unique) set of options, and a (non-unique) base domain url. Of course if you leave it to the browser then Chrome will probably allow at least themselves to track you, and Microsoft will re-badge it and point it back at their own tracking server.
Banning query parameters (the stuff after the “?”) doesn’t fix the problem sadly. A site operator could provide a start_url value like https://pwa.acme.com/start/123456 where 123456 is a unique number for each user. Voila, you can be uniquely identified.
Whilst the article appears to bemoan the fact that the issue is being left to browser makers to fix, I don’t see a reasonable and effective alternative. The solution needs to be where it’s most effective. Letting site operators like Facebook et al decide how to prevent tracking is laughable. The problem of course is that Google intentionally broke the Chinese wall by releasing a browser. The only practical solution to avoiding tracking in this instance is to have the browser makers fix the problem and keep away from Chrome.
Then take the spirit of the recommendation and not the letter, why allow anything after the tld?
Now, yes, a site could spin up unique subdomains, but, that's going to be harder work and would probably put most off.
Could not even allow sub-domains, you want a PWA, it'll have to run from the main domain.
That said, sounds a lot like a non-issue, if you like a site enough to use a PWA and add a shortcut to your homescreen you're probably going to want to be logged in to it anyway (like a weather app so you have your location stored, or twitter so you're logged in etc..).
Browsers already know that abc.com is a domain under the .com TLD and abc.co.uk is a domain under the .co.uk TLD. If you don't believe me check the address bar and see how the something in something.abc.com and something.abc.co.uk are either in gray or hidden.
Therefore it could enforce this so that something.abc.com and something.abc.co.uk aren't allowed, as well as banning parameter passing using ?.
There, not too difficult. Perhaps the issue should be reopened on github again.
I can't tell whether you're being sarcastic or not. All you've achieved is to (yet again) push the tracking to a different part of the URL - presenting: tracker-12345.com
Yeah, it'll cost me $5/year or whatever. Assuming I can't get free domains*. So all I need to do is add $20 to the price when I'm selling all your data and then cancel the domain after 3 years of inactivity.
Also blocking subdomains would cause a bunch of headaches. Having to register a new domain for my-app.com rather than using myapp.mycompany.com shouldn't be necessary and would be a pain for all the little guys out there.
The fact that there's money involved now means that this scheme would disproportionately affect individuals / small / open source projects while leaving the huge corporates (who are the ones doing the most tracking and slurping the most data) almost unaffected.
*if I'm large enough, I'll just buy a TLD (or use the one i already have, *cough* .google *cough* .amazon) and not pay that $5/year/user in the first place.
Have you looked at the current URL? Sure, the "forums" part is grayed out, but it's still significant, given putting that in puts you in a different part of El Reg versus the front page. Meaning you can't ban the "forums" part, for example, because there's too much risk for collateral damage, to the point you could end up blocking or banning the app itself.
As if "there'll be collateral damage" ever stopped a browser vendor. Basic auth in iframes, not showing www/m prefix even if what's shown has no A/AAAA record, the default changing from rel="opener" to rel="noopener", abandoning the CA/B forum, the list goes on and on. We are rapidly heading back towards "best viewed in X/Y/Z because Y/Z/X is broken".
This post has been deleted by its author
When they get to the point where they claim bookmarks are tracking you, you have to step back and wonder what the beef is with Apple WebKit developers trying to throw shade on webapps.
Why don't they just say: "we don't support that because we want to force you to use the AppStore"? It's not like the AppStore isn't tracking your AppleID too...
And they know it, too, because they now possess too much power for any one authority to control. This is the "Sprawl" solution to government oversight: become too big for governments to oversee. Now they can just dodge jurisdictions and so on to avoid regulation. Anyone gets too uppity, use your leverage to take them over.
If sites want to track you, they have the ability to do so completely server-side, meaning you're in a Hobson's Choice, which may not be a choice at all if your job (the only one at hand in this mess) requires your use of this privacy leech.
Can't think how I got along all these years without PWA's. Or mobile phone apps, come to think of it. Or anti-social media sites </sarcasm> Yeah, I know, just because I've never felt any inclination to use such doesn't mean that others don't find 'em useful, and good luck to them! But I feel sad that my one-time wonder at the fact that markup-languages made things like web pages possible has changed over the years to a combination of frustration and anger at the multiple invasive assaults on privacy that have resulted since. The future just isn't what it used to be! Sigh. OK, here's me shuffling back to my flat in the local home for mildly bewildered old biddies (Flat 1980, Vulture Eyrie Tower, Sodoff Street, Birminster, Barchestershire, UK)
"Trivial"* fix with a browser extension** from someone like EFF, where the extension sends the start_url (with no other user information) to a central server. If the server sees a high proportion of unique start_urls for a particular second-level or top-level domain, it responds that there may be fingerprinting going on, and the extension can warn the user.
* Relies on user installing extension, but the same is true of pretty much anything of this kind, including Privacy Badger.
** Assumes a browser extension can examine (but not manipulate) such requests. If not, perhaps the browser manufacturers should consider that extension point.
Biting the hand that feeds IT © 1998–2020