Who would have thought it...
It's nearly as simple as avoiding a parking ticket...
GitHub on Thursday said it has removed all cookie banners from its website, a decision the company is making in the interest of privacy, despite the claimed popularity of its disclosure interface. Cookies are files stored in the web browser upon visiting a website. They may be first-party cookies – stored by the visited domain …
And what is more they don't need first party cookies either, You can maintain state across a session using post or get variables..
Only if you want to login and stay logged in is it almost impossible without a cookie, at least if you want to close the browser in between visits. Browsers store persistent cookies, but not POST variables...
But in the end the answer is extremely simple and in user control.
Never buy anything that is 'pushed' at you, online.
Never buy anything that is 'pushed' at you, online.
Sounds like a good idea. The only problem is I already have a mental filter, years ago, that strains out most of the crap before it registers on my awareness. If anything ever manages to get past that, I have long intended to do as you suggest.
This should help the security and speed. I suppose it also helps the 25-50 year olds who do see the ads. At 60, I learnt to filter them out a long time ago.
This post has been deleted by its author
"Only if you want to login and stay logged in is it almost impossible without a cookie, at least if you want to close the browser in between visits. Browsers store persistent cookies, but not POST variables..."
A cookie should never be part of user persistence or other authentication, even if it happens to be easy on the server (a lot easier). Also, the only difference between POST and GET is in the URL caching. Both cookies and history/caching are dictated by the browser and can be configured. If the browser doesn't cache, POST === GET and if cookies are disabled, the server maintains sessions (which it does/should regardless). Although everyone hates Javascript now because it has been abused for spying, without Javascript everything becomes a deeper level of hell.
Also, Websockets, local storage, PUT/GET, etc. didn't change anything about security. Security is still all HTTPS and without it, it's all sort of plain text and equal in security (ie. not at all). That said, WASM can sort of blur the lines without HTTPS, but then most would consider that more of a threat than not using HTTPS. Of course even with HTTPS some still feel that way about the *potential* future of WASM (or probable future thanks to Google, FB, Amazon etc.).
"You can maintain state across a session using post or get variables."
But if you do, it gets painful. Whatever variables you use will end up clogging everything, from the user's history to your databases to all the HTML you send to them.
If you use get variables, the users' history, bookmarks, or shared links will contain a bunch of expired URIs which contain old session data which a) doesn't work anymore unless your server filters it out and redirects them to somewhere new which still works and is at least sort of like where they were at that point in history and b) may contain information that a user shouldn't be storing in their history. The second point can be thought of as the user's responsibility, but part of system design should be keeping data private even when it's not yours. If you instead use post variables, the user who returns to one won't have the issue of persistent storage of data but would likely get a warning from their browser that a post action will be repeated with possible consequences. This also doesn't fix the issue of having to handle links with inaccurate or missing parameters.
Meanwhile, you also have to have your system modify every element on every page to send the required data onto the next one. Turning every link into one which consumes parameters and passes them on and including hidden inputs which ensure all your parameters are in every form can be a large task which consumes resources, complicates the page, and makes your backend CMS a mess. If you don't do it, then a user who clicks on a static page which doesn't need the parameters but continues on from that page will find their session data has been lost.
Non of those entities sells the data they collect. Because the real "value" is there. They sell the targeting system built on those data. And the targeting system is mostly used to push ads to the targets.
GitHub data will flow into the larger cauldron of people's data MS is collecting from different sources, and used to sell targeting services.
It's also worth noting that the "usual suspects" of Google Analytics, doubleclick et al were all on my blocklist, (or rather, not on my whitelist) so they weren't tracking me anyway.
But if I block GitHub's cookies, GitHub stops working. So Microsoft can still track me, but now I can't stop them.
Microsoft already could, by running queries across server logs, because the endpoints belong to them. The difference is therefore purely technical.
I get your point, though, that api endpoints on a subdomain can't be blocked through hosts.
Not even the JFK assasination? The theory is that the man blamed is not actually responsible.
The twin towers? Industrial architecture is too good for two planes to bring it down that quickly.
You don't have to believe things to understand them.
The average persons is not that great at understanding complex stuff, but sky fairies and Illuminati are much simpler, conceptually.
To fake the moon landings and never a word leaked out nor a single mistake made is actually harder than landing on the moon. If you understand special effects etc.
The twin towers collapsed exactly according to their fire rating. 45 minutes fire protection then kiss the steel frame goodbye.
FWIW the underlying piece of info from which this conspiracy grew is a project to store some medical information onboard following vaccination.
"researchers developed a new type of copper-based quantum dots, which emit light in the near-infrared spectrum. The dots are only about 4 nanometers in diameter, but they are encapsulated in biocompatible microparticles that form spheres about 20 microns in diameter. This encapsulation allows the dye to remain in place, under the skin, after being injected."
A fantastic project which has triggered the technophobes everywhere
https://news.mit.edu/2019/storing-vaccine-history-skin-1218
I never understood the focus of that conspiracy theory on Bill Gates.
Elon Musk is actively working on installing chips into people's brains and his friend Peter Thiel founded Palantir ("For all your genocidal needs") and yet we're supposed to focus on some Kermit the Frog lookalike that has dedicated his retirement to eradicating malaria.
It's almost as if it's a deliberate 'look over there' strategy.
That's because it's a fake one, propagated to discredit conspiracy theories in general. :P
Fake conspiracy theory: 5G gives you coronavirus. The Coronavirius vaccine contains microchips which track your every move
Reality (conspiracy or not): 5G contains microchips which track your every move
(part of how it works - see: https://blog.huawei.com/2020/08/17/the-wonders-of-5g-beamforming/ )
Beam forming for location tracking? Irrelevant. Why? Because 2G, 3G & 4G networks track your every move through geolocation, if your phone signal is picked up by two base stations the network triangulates your position and records it, and much of the cell network is designed to have overlapping cells; and if your signal is only picked up by one base station, they know roughly where you are. The network needs to know to which base station your phone is attached, so it can route phone calls and data traffic to you.
So the beam forming capability in 5G adds little.
This post has been deleted by its author
Of course this does nothing to stop other methods of tracking.
Since users of GitHub are likely to be authenticated, in order to access their repositories, it follows that any API requests include that AUTH info, and therefore the back-end will have no issues with recording who does what. The end user has no control over what happens to that data, especially in the US, where the concept of privacy is as screwed up as their date formatting.
On the plus side, this does potentially stop every advertiser and their co-spawn from tracking your every movement. Somewhat.
Unless they're paying MS for that data, of course. In theory, GDPR stops them doing that with data about users in the EU (and for now, at least, the UK, but who knows what will happen with the disaster capitalist race-to-the-bottom here). US users, legally, are fair game, so it remains to see whether Microsoft decide to be ethical with their data or not.
I was going to say the same thing. Unlike (say) a newspaper site, the vast majority of accesses to github are from authenticated users.
The session cookie, which is necessary to permit access for each page view, handily doubles up to allow tracking of which pages you visit and in what order. They'll certainly be analysing that data.
unless the github cookies are used cross-site they'll just be showing how you view other people's repos on github. Somehow I don't think it's all that bad, if no advertising nor "what you see" adjustments are made from that info.
(that doesn't mean there's no 'web bug' on other pages that sneaks a peek at the github cookies to see who you are - that is STILL a possibility, right? Then again so is your IP address in some consolidated tracking database someplace)
Thinking of cookies (in general) there used to be this one plugin [that no longer works nd I can't find an equivalent last I checked] that could put ALL non-white-listed cookies into memory and NOT persistently on disk. You could click a button in the toolbar that would "flush" the memory cookies. Also they'd disappear whenever you closed the browser. So, not only could you white-list only CERTAIN cookies remaining after you close all sessions to that site, you could 'grey list' OTHER cookies so they'd work long enough to get past the analytics crap that login processes seem to want all too often. Then you can FLUSH those things when you're done.
That would make an EXCELLENT built-in feature, wouldn't it? But Firefox's UI changes broke th3e old one (as with many other UI-related plugins I liked having).
> there used to be this one plugin [that no longer works nd I can't find an equivalent last I checked] that could put ALL non-white-listed cookies into memory and NOT persistently on disk
Private browsing does that. I am not brave enough to use a browser in anything other than private mode.
The disadvantage with Firefox is that the shits spend all their time chasing the latest cool fad instead of fixing long-standing bugs, such as the one that doesn't let you see or remove cookies during a private browsing sessions.
> But Firefox's UI changes broke th3e old one
Which UI changes? Are you perhaps referring to the plug-in architecture changes? There were very good reasons for that, actually. Namely that plug-ins had wide open access to your entire computer (with your user rights), including every page and every aspect of your browser. They were security nightmares. Again, they could perhaps invest more time in developing safe APIs to let plug ins regain lost abilities in a safe way rather than pissing their time on idiotic stuff that could be done by, err, a plug-in.
the one that doesn't let you see or remove cookies during a private browsing sessions.
It's not as if that's a particularly difficult one to fix, they just need to show the right cookie jar in the UI (is the settings tab open in a private window? Then show the private cookies instead of the normal cookies).
> It's not as if that's a particularly difficult one to fix, they just need to show the right cookie jar in the UI
I think you might be overestimating the quality of Firefox's code or the ability, motivation or willingness of Mozilla developers.
It only took five years until some eventually wrote an extension for this.
... by Off JustOff on Pale Moon --- and no doubt on pre 57 versions of Firefox --- does all that and automatically destroys the non-whitelisted cookies,localStorage and IndexedDB objects immediately one closes the page.
No doubt the other browser has similar tools.
.
.
https://addons.palemoon.org/addon/cookies-exterminator/
This post has been deleted by its author
I don't understand where people get that patently idiotic idea from.
For a start, there is not even a mention of the word or concept of "citizen" in the Regulation.
To continue with, the very idea stands out as offensive to anyone with a passing familiarity with international law. An EU Regulation is quite simply not the correct instrument for that.
GDPR applies to people of any citizenship (not just EU) resident in the EU.
It applies whether the company processing the personal data is resident or non-resident in the EU - if it 'offers' services to EU residents (not just EU citizens), then the GDPR applies.
So it applies to (for example) a social media company registered in (non-EU) Ruritania that, by the magic of the Internet, 'offers' services to people resident in the EU. If the company does not wish to comply then it must not offer services to EU residents.
Of course, if the company has no presence in the EU, it is a bit difficult to apply meaningful sanctions, but the basic point is that processing personal data of EU residents is covered by the GDPR.
Note, residents, not citizens. So an EU citizen who happens to reside in (non-EU) Ruritania, using services offered by a (non-EU) Ruritanian company is not covered by the GDPR.
References:
Deloitte: GDPR Top Ten #3: Extraterritorial applicability of the GDPR
clarip: The Extraterritorial Reach of GDPR to United States Businesses
GDPR associates: Myths on the extraterritorial scope of the GDPR
Note (from the third reference): As per recital 23 of the GDPR, the mere accessibility of a website in the EU is not sufficient to ascertain the intention that a company envisages to target EU markets.
NN
Nope. How do people manage to misunderstand one of the clearest bits of legislation to come from the EU?
And why did you link to three random blogs when the actual text of the Regulation is available for all to see, in twenty-odd languages, and has already been linked above?
This is clearly an exercise in futility, but the biggest errors in your post:
> resident in the EU.
Not resident in the EU. When it comes to the data subject, the test is whether he "is in the Union".
> the company processing the personal data is resident or non-resident in the EU
A company is never "resident", and the processor or data controller need not be companies. The exact definitions are given (surprisingly) in Article 4 (Definitions) of the Regulation. It includes natural persons as well as various other things.
You do correctly state one of the other parts of the territorial scope, which is a test upon the data processor or controller.
Indeed, your offers of goods or services being accessible from the EU does not by itself imply that you fall within the territorial scope of the Regulation. But you left out Art. 3 § 2 (b).
Thank you for the corrections and clarifications.
One thing to note, the GDPR "was among 69 EU legal acts incorporated into the EEA Agreement by the EEA Joint Committee in Brussels on 6 July 2018."
Ref: EFTA: General Data Protection Regulation incorporated into the EEA Agreement
The regulations entered into force in the three countries of the EEA on 20 July 2018.
Ref: EFTA: General Data Protection Regulation (GDPR) entered into force in the EEA
The practical effect of this is that when you say, "When it comes to the data subject, the test is whether he "is in the Union".", from 20 July 2018, is for practical purposes "the Union and the three EEA countries (Iceland, Liechtenstein and Norway)".
Background: EFTA: How EU Law becomes EEA law.
NN
>Of course, if the company has no presence in the EU, it is a bit difficult to apply meaningful sanctions, but the basic point is that processing personal data of EU residents is covered by the GDPR.
if I recall correctly, there is a requirement that they must have a presence in the EU. Now, that doesn't mean they have to have a full blown office with staff in an EU member state, just a presence, ,which I suppose in the simplest and cheapest scenario is an office that can receive mail such that it can be passed onto a representative of the company.
It applies to data held on EU citizens, wherever that data is held in the world.
It's an EU law, but I am not familiar with the mechanism as to how it can be enforced with countries outside of the EU/EEA, but I believe it can be enforced, because we've seen more and more websites based in the USA taking action to be compliant, or where they can't be compliant, they detect where the users http request is coming from and reject it.
These ultimately emanate from a handful of central sources - such as Google - who deliberately design them to annoy end users with the goal of turning them against data protection regulation; the fairly frequent posts in on-line forums such as this one blaming the EU for these is astroturfing to ascertain the intended reaction (the obvious solution of using only strictly necessary cookies with no banner has been available all the while, it is just incompatible with a business model with privacy violation at its core).
Linked question, and probably just a google search away but.... if you don't use third party analytics tools because it's easier to throw a js and use somebody else's system to aggregate your data, and instead use your own web server logs to track ip's to countries and sessions etc.... I'm guessing no banner is needed because it's all in house (although this should be put somewhere in your general T&C?)
Won't exempt you from GDPR. Even first party cookies are limited in scope and the any data collected is also covered so that if you do, for example, pass nicht anonymous logfiles to a third party for processing without both advising the user, and giving them the chance to opt out, having a suitable contract with that third party, then you are breaking law.
They are probably designed to do that.. Yes, they are required to display the banners, but make them so irritating you hit accept just to get rid of the damn thing.
I've actually seen several banners where you have the option to accept all, or the option to reject cookies individually, and some pages can have hundreds you would need to reject..