In my country, citizens have an "ID" (a UUID, which most people don't know the value of!) and a social security number which they know - which has all the problems described above).
While the social security number may indeed change (doubly assigned numbers, gender reassignment, etc.), the ID needn't change, since it's the same physical person.
Public sector it-systems may use the ID and rely on it not changing.
Private sector it-systems can't look up people by their ID, but only use the social security number for comparisons and lookups, e.g. for wiping records in GDPR "right to be forgotten"-situations. Social security numbers are sortof-useful for that purpose because they are printed on passports, driver's licenses and the like. And they are a problem w.r.t. identity theft, and shouldn't ever be used as an authenticator (we have better methods for that).
The person ID isn't useful for identity theft, since it's only used between authorized contexts (disregarding Byzantine scenarios with rogue public-sector actors!). You can't social engineer your way to personal data using that ID unless (safe a few movie-plot scenarios).
So what is internal in this case? The person id is indeed internal to the public sector's it-systems, and useful for tracking information between agencies. They're not useful for Bob or Alice. (They ARE useful for Eve, or other malicious inside actors, but that's a different story, which realistically does require a much higher level of digital maturity across the entire society)
Eventually, I guess there'll be backwards compatible "pattern extractors" functionality retrofittable to existing "record-like" classes. This has been hinted at on several occasions.
Yes, exactly - now you're getting it. Or rather I get the feeling I failed to explain it well.
ArrayList predates generics.
However, ArrayList does have generics.
That's because generics were added to the language in a 'culturally backwards compatible' way: Existing libraries (i.e. libraries that predate the introduction of generics, such as ArrayList) could modify themselves to add support for generics in a way that is backwards compatible for the library: Code written before they added it continues to work and compile fine even against the new release that added generics.
The same principle applied to records would mean that LocalDate could have been updated to turn into a record in a way that is backwards compatible.
And it really works that way.. almost. You really can take an existing class (defined with `class`) and change it into a record (defined with `record`) and all existing code continues to work just fine. However, this means all your properties now neccessarily get an accessor function that is named after the property. And that is a problem for LocalDate specifically: It already has accessors and they are named e.g. `getYear()`. Not `year()`. That means if LocalDate were to be rewritten as a record, one of two very nasty options must be chosen:
* Break backwards compatibility: As part of upgrading code you must change all calls to `.getYear()` into calls to `.year()`. It's a total ecosystem split: Every dependency you use comes in 2 flavours, one with calls to getYear and one with year, and you must use the right ones. This is truly catastrophic.
* Have both methods. There's year() and also getYear() and they do the same thing. Which is the lesser evil by far, but it makes very clear that LocalDate predates `record`. Contrast to ArrayList: It is not all that obvious that ArrayList predates generics. It does, but if you were to design ArrayList from scratch after generics are introduced you'd probably make the same code. Maybe the signature of `remove` would have been `remove(T)` instead of the current `remove(Object)`.
Instead, obviously then, the best choice is to not make it a record. And that's my point: The best possible (possibly here perfection is the enemy of good, but, I'd have done it differently) way to deploy records would have included some way for localdate to turn into a record without the above dilemma.
Perhaps simply a way to explicitly write your accessors with some marker to indicate 'dont generate the default `year()` - THIS is the accessor for it'.
Had that feature been part of record, then LocalDate could have turned into one in a way that you can't really tell.
Totally agree, I was just pointing out to GP why LocalDate wasn’t a record.
(Date and Calendar should never be used in new code. Note how the new date/time API doesn’t have any conversions to/from old types (Date+Calendar), they only in the opposite direction)
Can’t wait for destructuring support for classes, though.
IBM has been, and still is, a big contributor to a bunch of Eclipse projects, as their own tools build on those.
The people there were both really skilled, friendly and professional.
Different divisions and departments can have huge cultural differences and priorities, obviously, but “IBM” doesn’t automatically mean bad for OSS projects.
I read the piece expecting precisely that; How to keep PII out of logs, which require a lot of adamant snipers with a lot of lead bullets. Passwords: Handled by IAM services. Tokens: Application frameworks which not to divulge. But Brian's phone number stashed in an innocuous case metadata field. Gaah!
Some of the same techniques apply, like using domain primitives, but some PII (like names and addresses) is eventually templated into flatter (text) values, and processed by other layers which do not recognize 'brands' as suggested.
Data scanners: Regexes are fine for SSNs and the like, but to be really effective, one would need a full-on Named Entity Recognition in the pipeline, perhaps just as a canary. (Wait, that might actually work?)
Dataflow analysis and control applies in a BIG way, e.g. separating an audit log for forensics, where you really NEED the PII, from a technical log which the SREs can dig into without being suspected of stealing sensitive info. Start there.
PHK’s piece assumes that there’s a clear and effective distinctions between the government and the juducial system:
The police can’t wiretap unless authorized by a judge (this could be backed by certificates/whatnot, and not just “ok, go ahead” as it is now.)
However:
Not all countries have this effective separation/independence between branches, and some countries which have so far enjoyed such separation are perhaps not so certain anymore.
Even so: I think the point still stands - there is a choice to make, and the current trajectory (EU’s ChatControl, and UK’s encryption ban), is what we’ll risk getting instead.
Even in the US which has those systems, they are not robust enough for me to trust handing over the state this kind of power over all modern communication. Never have the police had this power before, even with warrants.
Backdoored encryption makes everyone unsafe while not stopping bad guys from using actual encryption. And when the bad guys use real encryption, the police can still catch them- see the case of Ross Ulbricht.
The point doesn’t stand because the magic system that only lets the good guys decrypt if only the engineers would think harder simply does not exist, and framing it this way obscures that fact and paves the way for ChatControl or encryption bans, not user freedom. We had this debate before with the Clipper chip, and reason mostly prevailed. Now we’re having it again with even higher stakes and people are arguing to give in to a framing that assumes defeat.
O(n^2) issues can typically be solved using keyed lookups, but I agree that the base processing speed is slow and the language really is too obscure to provide good DX.
I worked with a guy who knew all about complexity analysis, but was quick to assert that "n is always small". That didn't hold - but he'd left the team by the time this became apparent.
More that half of Danish municipalities have equipped schoolkids with Chromebooks -- but some failed to limit which services thay could/should use and so effectively send the kids' personal data out of the country, which caused quite the furor.
I believe Chromebooks will damage childrens digital education. Especially in that age you learn by experimenting and such a system isn't made for that. It is made to display something an equally digitally unqualified teacher wants to display.
Sure, schools cannot offer administration for the numerous IT related issues some systems might have. But that is a secondary problem.
Denmark must become less dependent on the major tech giants when it comes to digital solutions in the public sector. Therefore, the Ministry of Digitalization is now starting to test a new open source solution.
This week, the Ministry of Digitalization is launching a new pilot project, where a group of employees will begin testing an open source alternative to the Microsoft Office suite.
Specifically, the open source platform in question is Collabora, which is based on the open source software LibreOffice. The employees in the Ministry of Digitalization’s department participating in the pilot project will have the Office suite in their case management system replaced with Collabora.
"As minister, I’ve spoken about the need to challenge our digital independence. Now we’re taking the first step ourselves in the Ministry of Digitalization with this new pilot project. I don’t delude myself into thinking that this means we’re ready to kick the tech giants out tomorrow, but I see it as a welcome step in the right direction. As politicians, we have an obligation to ensure that our IT systems in the future aren’t dependent on a few large companies," says Minister for Digitalization Caroline Stage.
The ministry is beginning tests of a new integrated document editing module in the F2 case management system, based on the open source platform Collabora built on LibreOffice. This means that ministry employees will test an alternative to the Microsoft Office suite and use open source document editing tools instead of Microsoft’s solutions like Word, PowerPoint, and Excel.
The solution will be rolled out for broader testing in the Ministry of Digitalization’s department on June 19, 2025. At that time, a group of departmental employees will have their Office suite in F2 replaced with the open source alternative. In the months that follow, the ministry will monitor and test whether Collabora can support the ministry’s workflows and needs in a satisfactory manner.
The upcoming testing work will focus, among other things, on functionality related to the ministry’s templates, formatting for government cases, use of 'track changes', tables, etc., and whether the solution can handle conversion to and from Word format without altering the layout of documents.
If the test period proceeds satisfactorily, the next step is expected to be a broader rollout of the open source alternative throughout the department.
Nearly all of state and local administration uses various 3rd party solutions which have bespoke Office add-ins and rely on close integration with the formats (and security models) on the Office suite -- and are likely shifting more heavily into Microsoft 365 specific features.
So it's not as simple as rolling out LibreOffice and calling it a day. Much less Linux.
Public sector it-systems may use the ID and rely on it not changing.
Private sector it-systems can't look up people by their ID, but only use the social security number for comparisons and lookups, e.g. for wiping records in GDPR "right to be forgotten"-situations. Social security numbers are sortof-useful for that purpose because they are printed on passports, driver's licenses and the like. And they are a problem w.r.t. identity theft, and shouldn't ever be used as an authenticator (we have better methods for that). The person ID isn't useful for identity theft, since it's only used between authorized contexts (disregarding Byzantine scenarios with rogue public-sector actors!). You can't social engineer your way to personal data using that ID unless (safe a few movie-plot scenarios).
So what is internal in this case? The person id is indeed internal to the public sector's it-systems, and useful for tracking information between agencies. They're not useful for Bob or Alice. (They ARE useful for Eve, or other malicious inside actors, but that's a different story, which realistically does require a much higher level of digital maturity across the entire society)
reply