You do understand that a CA may need to revoke a certificate with very short notice in case of something wrong (like a misissued overly permissive certificate) on their side, or a compromise that is "nobody's fault", anyway? This has always been the case; the CAs themselves are bound by contracts to revoke misissued certificates promptly.

The only sensible way if you have a service that needs to minimize downtime is automation. We may have got off pretending it's not for some time.

I for one actually think their proffered reason is the real one, kind of. You can request videos which they have in a readily available format, and they will redact and provide those. Not always without some persistence, though.

In this case, they don't have in place a regular means (discovered by the employees via minimum effort) to view those tapes. I don't expect it to be a huge hurdle for the NSA, but it's a legally sufficient hurdle. And yes, that sucks.

I would point out that they actually volunteered somewhat more information for the second request than merely giving simplest possible responses to the questions. I guess they calculated that being friendly doesn't hurt in this case. Granted, their first response was not quite as helpful before some correspondence.

I actually would bet they have too few employees working on FOIA, and those employees just don't want to make it more likely that people will challenge them. That's why a terse "no responsive documents" response may seem preferable when they consider it legally sufficient.

But they're not going to be strangers to redacting videos. In this case they just have a sufficient reason why they don't need to. They also cannot give out the tapes without checking what's on them. That would be reckless.

Well, yes... and no. What Meta can do is offer only a paid service. DMA and GDPR are not attempts to get something for free. But they definitely *are* attempts to make it illegal to use personal information as a valuable commodity.

So, I would say, they do target Meta's chosen business model and were very much a reaction to it. Now it is up to Meta to find a less objectionable business model that does not use personal information as payment for a service, or to leave. Forcing this was very much the intention.

Well, would you be happier if we eliminated you instead of the language that allows you to introduce these vulnerabilities?

Yet as a society, we can definitely legitimately make that determination. And there's no way this Meta's idea will fly unless the EU seriously back off from the core ideas behind GDPR, which has been in force since 2016.

Arguably the biggest point of GDPR is to decommoditize personal data. It does this by mandating that all processing of personal data must have one of four lawful bases. The two relevant ones are:

1. Required directly for the performance of a service. This would mean, for example, that you are buying a medical service, and it is impossible to perform that service without that personal data. In this case, you do not need to ask for consent (as long as there is an agreement for you to perform that service). Many companies request your consent in any case to cover their bases.

2. Consent. Processing of personal information can happen with the consent of the person. The tricky thing here is that the consent needs to be voluntary and freely given. For that to be case under the GDPR, a declination must not disadvantage the person in any way that does not directly and immediately follow from not processing the data.

So it is permissible to show the same amount of less relevant ads without a consent, because that is a direct and necessary result of not profiling the user. It is not permissible to otherwise, for business reasons, to disadvantage the person who doesn't consent. Otherwise it would treat personal information as a commodity, something of value given in exchange for something else, and EU has just decided that is not in its view compatible with the right to privacy. (You must also allow consent to be withdrawn at any time without negative consequences.)

So what Meta could legally do is only sell ad-free subscriptions in Europe for $14/month, and not provide any free tier.

Or it can provide a free tier. But if it provides a free tier, it cannot require consent to use personal information as part of that. It can opt to show generic ads to those who do not consent to the processing of their personal information. Yes, that is less profitable. Europeans are crying crocodile tears. Meta loses the ability to do that which it should never have been able to do, use people's personal information without their consent. It's on Meta to find a business model that both respects human rights and is profitable for them. Or stop doing business if it can't.

This gives me a weird idea.

Many programmers have moved away from QWERTY. Now of course QWERTY is also pretty arbitraryâ"as is the mapping between glyph and sound or letter. Yet obviously to the world non-qwerty solutions seem weird.

Would it make sense to develop a font that is optimized for programming (and/or a specific vision deficiency) and that has nothing to do with how the glyphs normally look like, but is instead optimized to be as unambigous as possible in the context used? I.e. forget that 't' looks like a vertical line crossed by a horizontal one; just try to develop that works best.

No. You cannot require consent as a condition for a service. That's a very major point of GDPR. Consent must be freely given. This means that the person whose information is being processed must not be disadvantaged by declining. (You don't need consent to do the processing genuinely required by the service requested by the person whose information is being processed. Consent is only one or the four legal justifications for processing personal data.)

Wrong. GDPR explicitly limits it to "data provided by the user", which (at least according to the position taken by the European Data Protection Board, which previously was the board that worked to implement GDPR) includes data provided incidentally, such as which web pages the user load, but very excludes derived data such as credit scores or other analysis computed from the provided data (as long as they themselves in isolation are not personally identifiable information).

Call it What The F*** You Want Filesystem.

Any virtual file systems, of which there are many, would be *VFS. While the collision here is unfortunate, I find it hard to blame Microsoft. If you make a VFS and add a single letter in front of it, you cannot claim some kind of ownership on that single letter to the detriment of all other VFS implementations. If Gnome wanted to prevent clashes, it should have picked a more distinguishing name than a single letter + descriptive term of art. More likely, they just wanted to give it a name so they can refer to it themselves, not intending it to be unique forever. You cannot have it both ways.

Isn't there an equivalent of sovereign immunity in New Zealand? If I understand correctly, the sovereign immunity doctrine at least in the US would bar such a suit against the government. Sovereign immunity is the concept that a sovereign cannot be sued for damages except in cases where it has waived the immunity (for example, by having a law stating that it is responsible for damages in certain types of cases, usually with an upper limit).

I presume no sane government would make a law that subjects the country to that large liabilities. Many countries have laws that provide for some kind of restitution from the state in the case of wrongful imprisonment, but it's hard to imagine an unlimited liability.

If the officers of the state did wrong, it may be possible to sue them for damages (also in the US), but good luck collecting billions of dollars from them...

Because employees are by far the single greatest asset of Google, and since it would be reasonable to believe that it's possible for more people being happy in a culture which is not toxic for a large part of employees. In other words, Google bosses may wish that these people would convert into their worldview, but barring that, they want Google to be a place where as many qualified engineers as possible can be happy. Well, not necessarily all of them (like probably any Vice President of Diversity), but I would bet that most people at the top would choose this kind of reasonable pragmatism. Any engineer at Google could not get a well-paid job elsewhere; it's certainly not only about money, and it's a two-sided deal; Google is not really in a position to dictate.

I think what lead into the firing was a serious overestimation of the radicality of this engineer's views compared to other Googlers. Having said that, I think many execs may have now come to the realization that there is a problem they were not aware of and which needs to be discussed and solved.

I used to work at a game company. Before that, and coming from the a Linux world, I had always wondered how people manage to get even the executables to reach hundreds of megabytes to gigabytes. Now I understand.

For example, the game uses compression, so it embeds zlib. It also uses something like 50 externally or internally sourced libraries, many of which also embed zlib. Some of those embed other libraries, which again may embed zlib.

I found more than 80 copies of zlib in the game engine source code and its embedded dependencies. There were also tens of png and jpeg libraries, zip libraries and Lua interpreters. For building and tooling purposes only, there were around ten Python interpreters. Also, there were some eight copies of different versions of the in-house developed container library (STL replacement). And that doesn't count the libraries we didn't have source code for.

Nobody in our team even had the slightest idea that was the case. In the Windows world, that's standard and best practices. I believe this is largely due to the somewhat sorry state and limited benefits of dynamic linking on Windows.

The Linux world proves properly versioned dynamic linking can be extremely beneficial when done rigorously. To fix a security vulnerability in zlib, you only need to update zlib, not every application. Memory is saved: Any executable pages in dynamic libraries are only mapped once. That means you have one copy of zlib in memory per system, instead of 80 per application.

Statically embedding anything does have its benefits, though, which is why the commercial world likes it. It means you won't get to debug weird problems because of broken libraries on a system. Containerization is the trend also in devops, and that means explicitly duplicating stuff yo make it easier to maintain.

I think his goal was to question the monoculture, the echo chamber within Google that considers fairly mainstream worldviews unacceptable. I think it was about much more than gender diversity. In fact, I think he succeeded, though he got fired himself.

The author did quote research purportedly establishing gender differences pretty extensively (though in a digested form by links to Wikipedia, but frankly, for a forum posting that should be good enough if the articles are sourced - you can go dig the sources). More than that, he didn't even say that is necessarily the reason half of coders are not women, but that an honest discussion of the underlying factors should be possible. I see the posting mostly as an attempt to open discussion on the theme.

The author especially seemed to criticize affirmative action - internal Google programs only open to minorities, and shuffling teams if they are not diverse enough, because supposedly non-diversity is always a result of hidden, structural bias in the society (which I believe it often, but not always, actually is - in case of skin color I'm quite ready to believe it is so; and in case of gender I'm sure there's lot of bias, but I don't buy the claim that there is *no* relevant biological difference between the genders that would lead into anything other than 50/50 balance in any jobs). Choosing people on their outwardly apparent merits as you vouch for is the largely conservative choice here; the problem is that it often seems to lead into having white male majority in tech jobs.