marten-de-vries

I think 'rearchitect' should be interpreted as 'redesign the UI', not as 'start from scratch'. Most big changes seem limited to the UI (and done as part of a Qt -> QML migration). And it looks they'll do even those piecewise:

> In order to get the release of 4.0 out as fast as possible, we will be porting over many of our less used interface elements and dialogs directly from MuseScore 3. The plan is to gradually replace these with redesigned versions (built in QML) in subsequent releases (4.1, 4.2, etc.).

That doesn't sound unreasonable to me.

The original story is by the Dutch magazine 'Vrij Nederland': https://www.vn.nl/trump-twitter-hacked-again/ . Most Dutch news media run the story currently, including broadcasters NOS and RTL, news sites nu.nl and Tweakers, and (the websites of) newspapers Volkskrant, Parool, Telegraaf.

As andlarry writes in another comment, The Guardian seems to have a quote from Twitter denying the story, though: https://www.theguardian.com/us-news/2020/oct/22/trump-twitte...

That's the case because you speak English. Think about the last time you had to navigate a website in a language you didn't speak (in my case e.g. Chinese or Russian). I remember being very happy with a few (incomplete) clues in English about were to look and what to expect.

By all means, advocate for making it easy to change the language back to the original. But this stance will decrease accessibility.

Last I heard, KaiOS was working on migrating to Blink (https://news.ycombinator.com/item?id=19012709). Looks like Gecko isn't out of the running yet, which is good news from a browser engine diversity point of view.

I'm curious how this'll work out, especially with Mozilla making good progress on the new Firefox for Android as well lately.

In practise, end-users will probably not setup a TOR(-style) network themselves. That means you'll need to do it for them, so they still have to trust you. At that point, just not storing their IP address is probably easier.

There are still advantages to the TOR-style solution (you wouldn't have the ability to track users without resorting to backdooring), but the slowdown and extra complexity is probably not worth it in most situations.

> However, there is an unspoken claim that the gradient update doesn't carry enough information about the user data to reconstruct any of it server-side.

This was a concern for me as well, but the 'Privacy' section of the post addresses this. In short, the algorithm is adapted such that the influence of a single user on the model is limited, and noise is added. I'm not knowledgable enough on differential privacy to know if that covers all possible privacy attacks, but it looks like a good start.

Personally, I'm now more worried about adversaries trying to mess up the model. How many clients need to submit fake updates for the training process to never converge? If it's 50% that's probably fine, but I'm afraid a much smaller amount of users could derail the process already.

Your customer service should know how to deal with product warranty. Or should be able to handle a request to cancel an online purchase for 14 days after the order ([1]). How is making a request to access your personal data different?

[1]: https://europa.eu/youreurope/citizens/consumers/shopping/gua...

That's not the whole story. There are further responses in that thread, including the opposing viewpoint from the TunSafe author.

* https://lists.zx2c4.com/pipermail/wireguard/2018-March/00246...

* https://lists.zx2c4.com/pipermail/wireguard/2018-March/00246...

are the most relevant ones. (There are more, but they go slightly offtopic.)

From the GDPR, recital 45:

> [...] where processing is necessary for the performance of a task carried out in the public interest [...] the processing should have a basis in Union or Member State law.

I don't think that purpose of archiving has a basis in law.

That said, I do remember my law professor calling the 'right to be forgotten' one of the weaker parts of the GDPR, and I'm not an expert, so it's possible I'm missing something.

And Facebook has the right to 'inform' another company about all data it collected from its users (only in exchange for a nice sum of money!)

Except in the EU, freedom of speech and privacy are both considered human rights, which need to be weighed against each other. Freedom of speech will win when someone uses the GDPR to try to censor e.g. an online news article with some personal facts. But it won't for my Facebook tongue-in-cheek example, and I doubt it will for the redacted committer example either.

That makes sense for repository users keeping a private copy.

But, I was thinking more about companies like Github. If they can hide behind that clause for every single repo they host, the GDPR as a whole becomes useless. Pretty much everything could serve as evidence one day. As far as I know, judges don't like 'hacks' like that.

Also, additionally, code hosting platforms argue they are service providers and should not be liable for copyright infringement as long as they apply notice and takedown.

There's an exception 'for the establishment, exercise or defence of legal claims.', but there's situations where that would not apply. E.g. commits fixing a single spelling mistake are probably not copyrightable.

Also, I doubt you can just keep a copy of all data you ever process, just because it might some day be useful as legal evidence.

> Paragraphs 1 and 2 shall not apply to the extent that processing is necessary:

> [...]

> (d) for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) in so far as the right referred to in paragraph 1 is likely to render impossible or seriously impair the achievement of the objectives of that processing;

(emphasis mine)

I'd not say redacting a git repository does 'seriously impair' processing for archiving purposes. All the data (with the exception of the redacted e-mail) is still there, after all.

Still, the hashes will have changed, making the repo less useful for current users. But that has nothing to do with archival.

It's interesting to see how the GDPR seems to clash with some popular data models. For example, git.

Rewriting history of a shared branch is disastrous, but it's currently the only way to redact, say, an e-mail address someone committed with a couple of years ago. I'm curious how the various code hosting sides plan to handle that. Perhaps we'll see an extension of the data model that links commits to committer UUIDs, with the actual information being linked to that, making removal easier.

I don't think so, or the language would have died out already. I'd argue it's more about whether children learn it as their primary language.

Also, because of concerns of linguistic extinction, similar to the ones mentioned for Icelandic in the article, you see somewhat of a counter-movement as well. This caused e.g. a special status of the language by law (see e.g. [1]), and also:

* it's a mandatory school subject

* you are entitled to using it in government interactions, e.g. in court

* a small part of the public television is in Frisian, and there's also a regional tv/radio channel using it exclusively

* place name signs are often at least bilingual, and sometimes Frisian-only.

[1]: https://en.wikipedia.org/wiki/European_Charter_for_Regional_...

There's a middle road, you know: being bilingual. To run with the Icelandic example, you'll be hard pressed to find someone who speaks it but not English.

Where I live, there's also a local language (Frisian) spoken beside the 'bigger' language (Dutch). And here too, lots of people speak English. Or if not, you might get lucky with German.

Ah, seems like the situation is better than I remembered. I confused colored syntax highlighting with the default settings, which highlight using font weight/italicness etc.

I did try minted once, but never used it in practice. The dependency on pygments making the documents more system dependent is less than ideal.

Now add syntax highlighting. In Markdown, it's trivial (```language-name), in LaTeX, you're going to have to define a style. LaTeX is more flexible, but it does come at a cost.

The article seems to argue for a GDPR[1]-like equivalent in the US. It'll be interesting to see how it is enforced in the EU. If applied as intended, it could offer a more realistic alternative to the only other privacy-preserving option at the moment: not using Google/Facebook/etc. 'noyb'[2] is planning to help that along. I just hope we don't get another cookie-law like debacle.

[1]: https://en.wikipedia.org/wiki/General_Data_Protection_Regula... [2]: https://noyb.eu/

I'm curious if developments like this will mean future cars will not require lights at all. After all, the same communication required for an intelligent traffic intersection like this could just as well be used to exchange breaking, lane changing and position information.

They do not violate the relevant specification. They just implement it in a way that has not been done before with the user's convenience in mind.

That aside, your position is unrealistic: browsers regularly break non-spec conforming websites. They actually monitor such cases (telemetry) and try to work with popular websites to fix the issue before they ship the breaking update, but it's a tradeoff that is regularly made nonetheless.

I agree it would be great if other browsers implemented this as well, but you lose me at:

> The best thing Mozilla could do is convince Apple and Microsoft to give up their independent lackluster browser implementations and ship Firefox as the default instead.

Multiple independent implementations are of vital importance to the web. We've seen it with IE6 before, and having two browsers is cutting it too close.

From the article:

> Scripts are delayed only when added dynamically or as async. Tracking images are always delayed. This is legal according all HTML specifications and it’s assumed that well built sites will not be affected regarding functionality.

(emphasis mine)

Yes, that's my hope. For the income of website owners it is better if they all collectively block their site until the trackers are fully loaded. But if only a few do so, users might avoid their site, so individuals are still encouraged to support delayed loading.

I imagine Mozilla is in a similar situation: if too many websites block, they will have to disable the delay or start whitelisting trackers if they do not want to loose users. That is, unless other browsers follow their lead here.

Prisoner's dilemmas all around. It's going to be fun to see what we'll end up with, although I'm optimistic as I haven't heard complaints about this yet, but then again I wouldn't notice any difference myself as I'm already using NoScript.

Interesting approach. I hope more browser vendors will adopt it. It comes with an additional advantage: if a website still needs to function when tracking domains are delayed a second or so, they likely will function too with said domain completely disabled (e.g. using extensions). Sounds like a win from a user perspective.

Full title: "I am Max Schrems, a privacy activist and founder of noyb.eu - European Center for Digital Rights. I successfully campaigned to stop Facebook's violations of EU privacy laws and had the EU Court of Justice invalidate the Safe Harbor agreement between the EU and the US. AMA!"

The AMA is currently ongoing.

Exactly. It's there to (very mildly) confuse you.

No, they're not in it for money. In the end (the foundation owns the corporation), Mozilla is a non-profit.

They need money to achieve their mission though: maintaining a browser (in a landscape of evolving security challenges, performance & web standards) and research (e.g. projects like Rust, Servo & pdf.js originated that way) is not cheap. And currently it mostly comes from search engine deals. If they cannot get a similar one, it all collapses.

I can see why they try to diversify their income. That said, I don't agree with the way they do it here.

As using webhooks for git repositories is probably the most common usage, it would be really nice if the different APIs converged here. Now everyone is inventing their own (and I'm in fact guilty to this myself for a side-project).

I found out about this standard myself indirectly during a web search. As an outsider to the w3.org process, I think the best way is to follow working groups with themes you're interested in: https://www.w3.org/Consortium/activities. For example, WebSub is worked on by the Social Web Working Group: https://www.w3.org/TR/tr-groups-all#tr_Social_Web_Working_Gr....