bozho

It's exactly that marketing worda for tamper-evident audit log

I've listened to Tang's talks a number of times. A great example.

and also, this is some non-obvious practice for people who are not security experts. They answer honestly because that's what they are asked

Even 10 euro a month per user is nothing - their salary + insurance + taxes is probably 3-4 thousand euro at least, these 10 euro are a statistical error.

We use Office365, because we need Office anyway. We initially used a hosting provider email server, but it's not trivial to get the email DNS configuration right, and you risk going in spam. Even after we got our configuration right, we still had occasional "spam" issues.

it was a deliberate reference :)

And yet, they do have it ;)

Some thoughts on when it's ok to use JWT https://techblog.bozho.net/using-jwt-sessions/

a) companies had 2 years go comply. Furthermore, the guidlines of the European Commission are clear that the process should be gradual - inspect, write recommendations, small fines, bigger fines. Nothing like "20 million in June"

b) the law had to cover a lot of usecases and in order to do that concisely, it may sound vague in places. I also don't like (developers never like uncertainty), but there's established practice already in regulators and courts about what is considered "adequate", "appropriate", etc. I agree it could've been better though.

c) that is happening already, e.g. ICO (the UK regulator) has a pretty good set of guidelines and examples. There's also the process of "prior consultation" where if you are not sure about something, you go ask your regulator for a decision

d) this is exactly what the "proportionate", "adequate", etc. are in for. If you are a small company with 2000 data records, you are not posing a high risk for the rights and freedoms of data subjects and so most of the things are not a strict requirement

A few clarifications (author here)

1. yes, you are correct, most of the features don't need to be implemented in code and having documented procedures would be sufficient (and that is pointed out in a number of places in the article). However, if you are not a small business or have a lot of users, the time needed to implement the features will be negligible compared to the amount of time needed for handling manual requests.

2. The "legitimate interest" legal basis is harder than it seems and many regulators warn against its overuse. Lawyers in my country are skeptical that regulators will accept legitimate interest in many cases, so "to be on the safe side" they recommend relying on consent. Again, as pointed out in the article, this is up to the legal team to decide.

3. The right to be forgotten is valid even under legitimate interest. Article 17(1)(c) is clear about that - whenever a user objects to their data being processed on the basis of legitimate interest. It is a bit hidden, as Article 17 refers to Article 21 which in turn refers to Article 6, but you can piece the whole scenario anyway.

4. About the best practices - agreed, they are not mandatory under the regulation (as pointed out in the article), but having them in place will demonstrate a higher level of compliance.

It is practically the same thing, yes. But the use-case here is different - you don't need everyone to be able to confirm everything. You need to be sure that your data was not tampered with.

it is just a part of the blockchain, namely the "chain" :) But thanks

That is true. That's why it's "blockchain-inspired". In the whitepaper there's an explanation why the distributed aspect / byzantine fault tolerance is not necessarily applicable in this case.

It only pushes the top of the chain every X hours, just creating "safe points". Not all data is pushed to the blockchain of course, it will be too expensive to begin with

Exactly. And that's good enough. The question whether contributors "are welcome" is less relevant now than it was 5 years ago. But I think they still are.

Exactly. Niantic apparently knows how do to things. Or at least they knew

Revolutions normally don't fix problems, they create new ones.

That is irrelevant to the topic. Yes, there are big problems, but they are not fixed overnight. They are fixed slowly and patiently by introducing ever more transparency and safeguards.

From the electoral code, rough translation: "Independent observers are allowed to verify whether the digital fingerprint of the system in the data centers matches the publicly announced one"

Actually, we made sure that the e-voting provisions in the new electoral code explicitly require the whole software to be open source. Especially for voting this is mandatory, otherwise there is no trust.

Yes, in the linked presentation I mention GDS as a good example. The US also has a lot of opensource projects.

Although not strictly "defunct", point taken - changed it to LibreOffice.

Tech journalists keep ranting about the bad pitches they receive. They publish tips and guidelines. But even if you follow those, they still don't read the pitches. And rarely have any idea about technology http://web.bozho.net/?p=336

that is true in some very rare cases. CPU-intensive bits of the application should definitely be separated, so that they can scale independently. But that's not the main point of microservices.

my reasoning of whether something is spam or not does not change other people's reasonong whether something is spam or not, but to claim something is objectively spam is a bit too much. Apparently the notion of "spam" differs.

Twitter is constant self-promotion - you constantly share your thoughts and views. And somehow that's fine and you get followers. Is tweeting spamming? Besides, see the other comment with the chart attached.

when in doubt, consult the data :) Thanks for sharing.

facebook is using php compiled to C++, and that's only for their frontend. Mind your anecdotal evidence :)

Counting keystrokes in programming is like counting letters in a novel - the amount of time put to think of something, to discuss it, takes the vast majority of time. Keystrokes used to write something is irrelevant (especially if you type with more than 2 fingers)

And if the whole arguments boils down to Java not having a var/val keyword - yes, that would be handy; but you would then still need tools to figure out what is the type of val foo = calculateSomething();

There is a point in my presentation that says that some of these annoyances are easy to overcome in a real project. But some of them aren't.

As for the misunderstandings - the "bad" parts are ..bad. The ugly parts may not be bad, but are ugly (which is subjective, and I think it's implied it's subjective)

Unfortunately, there are too few countries. Portugal, Spain, Estonia, Finland, Belgium, India and a few more. Everyone solves the problem in their own way, sometimes incompatible with the others, and not taking into account all privacy concerns. Hence my suggestion for a standard, interoperable solution