Threads for jessicah
-
I don’t understand how some pretty big companies get something so obvious so clearly wrong. UUIDs are pretty decent for very large systems, and a bit more random than an auto-incrementing integer. And pretty easy to add unique constraints on email addresses. I built a system that integrated with multiple different external systems, with separate email addresses for each, as some people surprisingly had different email addresses between the different external services.
Also, services using email addresses as primary identifiers makes moving away from one email service to another extremely difficult :(
-
jessicah
1 month ago
|
link
| on:
FSF: Chrome’s JPEG XL killing shows how the web works under browser hegemony
Disregarding the FSF, JPEG-XL has clear benefits, and has had wide industry support, essentially waiting on Chrome to add it to make it usable on the web. And despite how the FSF statement is written, the overall theme of the browser hegemony is correct. If Chrome doesn’t play ball, you’re screwed. Chrome is the new IE of web standards.
-
jessicah
1 month ago
|
link
| on:
Displaying My Washing Machine's Remaining Time With curl, jq, and pizauth
It would be better if these were local network only APIs, rather than going through a cloud intermediary, that may change at a whim. Going via a remote server is just bonkers, and splatters more of our PII over random cloud services. I get it, it’s easier to develop an app that talks to a server you control, but with stuff like Thread/Matter now standardised, I’d like to see this random cloud dance disappear for what should be local control of local devices/appliances.
-
There are good reasons for a cloud service. A single machine can easily act as an MQTT server handling events for tens of thousands or more devices. It would be inefficient to require every consumer to run one of these. A cloud server is also accessible remotely, which can be useful if (for example) you put the washing on to finish when you got home but discovered that you’re delayed.
That said, being locked into a single provider for the back-end services is obnoxious. Reconfiguring a washing machine to point to a different service is a hard problem, since adding USB / UART would add to the BOM costs noticeably and it doesn’t have enough of an on-device UI to enter configuration info. I can imagine doing something like mDNS-SD to find SRV records that would overwrite the default configuration, but ideally you’d avoid a compromised phone that a guest brings to your house being able to take over configurations, so you’d probably want these things to be signed. For technical uses, it would be fine to have a QR code with the device’s public key on it and require a specific mDNS record to exist containing a connection string signed by that key to override the defaults. You could quite easily write an Android app that scan the QR code and publish the right record. If the updated connection strings are sticky (or rechecked only when the washing machine is reset) then you wouldn’t need any local infrastructure.
-
Having a cloud service is both simpler to develop and allows the vendor to capture part of the “customer experience” after sale. Like I mentioned upstream, the fact that Miele is nice enough to allow a customer to create their own apps via Oauth is (in my experience) unusual. Usually the vendor wants all that data and functionality for themselves.
-
-
You’re going to have a lot of wells to unpoison when it comes to this claim–especially given dark patterns such as not asking for consent around tracking in general. I don’t think folks argue it’s “telemetry = bad” but all of the mishandling of data we’ve seen and, without the source, it’s hard to to just “take their word” on what they’ll collect or that it won’t be abused in a future release.
-
I don’t think folks argue it’s “telemetry = bad”
I think that this is exactly what folks argue. At least that’s how I perceived the reaction to Russ proposal to add ‘transparent telemetry’ to Go. In fact, the discussion on lobsters showed that many (if not almost all) who argued against it didn’t even read the proposal.
-
That’s exactly the poisoned-well issue, though: there are enough somewhat credible accusations against Google that the actual data handling practices have in fact been incompatible with the literal reading of published documents. And any big org has stories about higher-ups overriding carefully balanced planning from the technical teams. Oh, and nobody doubts that Google can get both code and transmitted-data obfuscation done.
In this model — supported by many people’s evaluation of facts (mine included) — reading a proposal indeed cannot remove the worries, so some people just skipped it.
-
-
-
It can be used as an excuse to remove features that only the telemetry-naysayers are using, since the telemetry shows no use of said features. Before telemetry, someone had to formulate an argument for a feature removal, now the burden of proof has moved to those who want to keep it.
-
-
-
-
-
I think it’s true that a lot of people didn’t read the proposal, and more so the further you got from the original discussion on GitHub (I didn’t follow that one on lobste.rs, but I did see some nuance-lite posts on mastodon). But in spaces where it was more constructive, the message was much more clearly “must be opt-in.” And hey, they listened.
-
-
-
I think it was Audacity that had added telemetry …. in the form of Sentry bug collecting. People really got super pissed off and I was honestly a bit flummoxed. Surely bug reports are reasonable at some level?
It does feel like the best kind of telemetry is the opt-in kind. “Tell us about this bug?” Stuff like Steam has user surveys that are opt-in. It’s annoying to get a pop-up, but it’s at least respectful of people’s privacy. I have huge reservations about the “opt in to telemetry” checkbox that we see in a lot of installers nowadays, but am very comfortable with “do you want to send this specific set of info to the developers” after the fact.
-
IIRC, Steam also shows you the data that it has collected for upload and gets your confirmation before sending it.
I also appreciate that they reciprocate by sharing the aggregated results of the survey. It feels much more like a two-way sharing, which I think really improves the psychological dynamic.
-
Unfortunately, bug reports are just a single facet of product improvement that seems to get glossed over. If you can collect telemetry and see that a feature is never used, then you have signals that it could be removed in the future, or that it lacks user education. And automatic crash reporting can indicate that a rollout has gone wrong and remediation can happen quicker. Finally, bug reports require users to put in the effort, which itself can be off-putting, resulting in lost useful data points.
-
If you can collect telemetry and see that a feature is never used, then you have signals that it could be removed in the future, or that it lacks user education.
But it can be very tricky to deduct why users use or do not use a feature. Usually it can not be deduced by guessing from the data. That’s why I think surveys with free-form or just having some form of channel like a forum tends to be better for that.
A problem with both opt-in and opt-out is that your data will have biases. Whether a feature is used by the people who opted in is not the same question as whether people (all or the ones who pay you) make use of it. And you still won’t know why so..
There tends to be a huge shock when people make all sorts of assumptions and then because they try them and they still fail they start talking to users and are hugely surprised by thing they never thought off.
Even with multiple choice surveys it’s actually not the easiest. I am sure people that participate in surveys of technologies know how it feels to when the data is prevented give wrong assumptions as interpretation.
It’s not so easy and this is not meant anti-survey, but to say that this isn’t necessarily the solution and it makes sense (like with all sorts of metrics) to compare that with actual (non-abstract/generic) questions to end up implementing a feature, investing time and money only to completely misinterpret the results.
And always back things up by also talking to users, enough of them to actually matter.
-
But it can be very tricky to deduct why users use or do not use a feature. Usually it can not be deduced by guessing from the data. That’s why I think surveys with free-form or just having some form of channel like a forum tends to be better for that.
Asking users why they do/don’t use every feature is extremely time consuming. If you have metrics on how often some feature is getting used, and it is used less than you expect, you can prepare better survey questions which are easier for users to answer. Telemetry isn’t meant to be everything that you know about user interactions, but instead a kick-off point for further investigations.
-
I agree. However that means you need both and that means that you cannot deduct a lot of things simply by using running some telemetry system.
Also I am thinking more of a situation where when you make a survey and add (optional) text fields to provide context. That means you will see things that you didn’t know/think about, which is the whole point of having a survey in first place.
-
-
-
-
That’s something I’m not so sure about either though. I don’t really have a problem with anonymous usage statistics like how often I click certain buttons or use certain features. But if a bug report includes context with PII I’m less keen on that. Stack variables or global configuration data make sense to include with a bug report, but could easily have PII unless it’s carefully scrubbed.
-
-
Can a designer explain what the word “stack” means in this context?
Is this a website that showcases my OS’s fonts?
-
-
Is this a website that showcases my OS’s fonts?
The site tries shows font styles that are already available on people’s computers as part of their system fonts. If you pick one of these font listings for your CSS, then you don’t need to use web fonts. In that way, this site connects with the Stop Using Web Fonts article that’s also on the front page.
-
-
Yes, but formalizing what you used to do across platforms you hadn’t considered at that time. Basically it’s helping to answer the question “how am I most likely going to get a passably similar aesthetic across the permutation space of pre-installed font choices made by disparate vendors that don’t communicate with each other and can’t agree on a standard?”
-
I remember fiddling extensively to get fonts to appear similar in Windows/IE4 and Linux. Windows at the time had the meticulously hinted Verdana/Georgia/Tahoma TrueType fonts, whereas Linux (I think) only supported Type1 and bitmap fonts, and certainly couldn’t do hinting. Type1 fonts didn’t look good until you increased the point size to about 12-13, which was frankly too large for a resolution of 640x480.
I didn’t have access to a Macintosh at the time, and neither did anybody I knew, or I probably would’ve included them in my attempts.
I have to say, what the author did looks very good (and certainly better than my attempts at the time). I’m just amused by the word “modern”.
-
Pretty sure the “modern” is just to bring the stack collections up to date with current device trends; most of the other such stack recommendations out there are several years and numerous device generations out of date. The underlying problem predates the Windows/Mac/*nix trichotomy by at least the Gutenberg Press.
-
-
-
-
-
-
-
-
In this case, it’s just a list of operating system native fonts to use for similarish appearances. You can see more detail at the GitHub page: https://github.com/system-fonts/modern-font-stacks.
-
-
So the primary takeaways are if you care about performance, don’t use Java, and Rust is decent at quickly bringing up a new service with less footguns than the equivalent C/C++.
Was surprised there apparently wasn’t a caching layer in front of the databases already, too. That seemed like an obvious easy win.
-
And so we have moved from ‘no such thing as themes/modes’ to ‘a nice feature some users appreciate’ to ‘not offering this feature is SWATting your users’.
-
I realise we’re on the internet, but this seems a bit of an uncharitable interpretation?
The author’s offering an actual solution to a problem that some people have. I didn’t see any discussion as to the moral rectitude of dark vs light mode.
I will admit I never really considered dark mode to be an accessibility feature until receiving a request for dark mode on app that was going to be used in darkened industrial control rooms. For some people, it really is important.
-
offering an actual solution to a problem
It’s not that easy. If you setup a whole theme you have to change a lot more. If you have images, they will still have white background. If you use SVGs (to scale it better, hello fellow 4k users, “please don’t blurry me”), then you probably have black lines on black background now.. There are tons of other tiny things that can break, and I don’t expect people who actually just write some blogs to test this for every configuration.
-
You can recolour SVG with CSS, that’s one of the biggest benefits to SVG
-
-
-
-
Maybe ship the CSS of your choice and let your browsers reader-mode take over from there for all the custom requirements of others ? Otherwise I’ll probably just default to no CSS, so it looks like disabling CSS completely. And even that won’t work very well if you need colors for Code highlighting.
-
-
-
-
Honestly? I feel like you need to personally be slapped with a large trout.
Is that “advocating physical violence”? or “a ridiculous sentence born of exaggeration that’s telling you to lighten the fuck up”? You decide!
-
Not particularly…in many computer games, notably the Counter-Strike series, a flashbang was implemented with a bright white flash that fades. (At LAN parties, you could always tell a successful flash by the CRT lighting up an opponent’s face and the wall behind them. Good fun.)
I figured the author was alluding to that big white flash upon switching to a new web page that did not handle that dark mode preference gracefully.
-
Clearly it’s a joke.
-
People tend not to sugarcoat unpleasant things. When I was asking support of a brokerage service/website about their plans on adding dark mode, I described their then-super-bright website just as it felt: that it resembles an interrogation when I’m using it in the evening.
Got a chuckle from the support person. They suggested using browser addon but added dark mode some time later anyway.
-
-
-
-
-
Because the title of the post is just as inflammatory (in wording as well) and everyone vibes with this response. If someone doesn’t like how a website looks then I’d suggest using an extension to force it instead of asking politely through a setting that may or may not be supported. dark reader seems decent.
-
-
Flashbangs are typically used by SWAT teams when entering premises occupied by possibly hostile individuals. This isn’t that much of a reach tbh. I don’t see why it bothers you so much considering the OP was just as tongue in cheek. It’s web stuff, barely technical, the post has already been flagged a bunch, and the responses reflect the effort.
No reason to expend a ton of energy here, gonna go play with stable diffusion.
-
because upvote-based discussion boards create positive feedback loops for reactionary paranoia and every forum of that structure devolves over time to produce the same type of discussion structure and lenses on how to interpret content. reddit, HN, lobsters, digg before it … this evolution happens over and over and then someone goes “i know, i’ll fix this by making a new community with better moderation” instead of questioning the fundamental voting structure that underpins every one of these doomed communities.
-
Don’t forget Slashdot!
-
-
I’m not at all convinced voting is the right model, because the people that don’t know about a topic vastly outnumber the people that do know about a topic. Maayyyyybe a pagerank-adjusted system but that has a huge bootstrapping problem, I’m not sure how you’d get that off the ground. Voting isn’t really the goal anyway, the goal is good discussion.
-
-
-
-
Opening a white webpage while using darkmode feels just like getting hit with a flashbang in a first-person shooter. That’s how I understood the title, and as a darkmode user and Counterstrike player myself, I fully relate to that description. The analogy doesn’t sound inflammatory at all. In fact, it’s quite accurate.
-
-
I can only speak for myself, but I upvoted the parent comment because I feel that the submission doesn’t bring anything to the table other than its baity title. It looks like the work of less than a minute. Measured, descriptive, non-sensationalized post titles are an important aspect of Lobste.rs for me.
The comment in question has most of the same problems as the story itself, so I don’t exactly love it, but shrug.
-
-
-
You can take advantage of HDR in Safari: https://kidi.ng/wanna-see-a-whiter-white/
-
-
-
-
-
-
-
Continuing trying to get zig working on Haiku. It’s getting closer, but a two hour iteration loop is painful!
-
-
It seems to be a Haiku specific issue, that I’ve got no idea about. I saw “page daemon”, which ensures pages are available, spiking a lot so I disabled that entirely (the zig build uses ~13GB), but that was a red herring.
Unfortunately, I don’t have a working backtrace in zig yet, and Haiku’s Debugger just shows what looks like absolute nonsense, with stack frames including functions that should never get called, so it’s a bit of a black box right now :-/
Can see this for the nonsense: https://gist.github.com/jessicah/555a4d36995b96aae79bf5137e7feaa3
-
-
-
When I was working at Uni, they implemented a password history policy like that. So I went through a whole bunch (~16 or so) of random password changes to get back to my previous already pretty secure password (15 random alnum) :p Forced password rotation is probably the worst thing IMO. Well, that, and systems that email you a plaintext copy of your password, and then it’s like “oh, #$@!”.
-
[Haiku] has seamless support for:
- Immutable system directories
- Rollback to previous states
- User-managed packages separated from system packages
This actually sounds a lot like NixOS (plus home-manager, for the third item). Haiku seems to have had way more work put into user-friendliness and approachability, though.
-
I was thinking exactly the same - Nix is such an incredible pain to manage. I wonder if Haiku’s packaging can be programmatically leveraged like Nix, so you can create workspaces with pinned packages for your projects (i.e. have programs installed in the project workspace that are either not present in the global system or at different version combinations).
-
-
The user-friendliness & approachability took multiple years to fully get right. I discussed that a bit in longer reply below, but the full history of that era in Haiku’s history (2012-2016) has yet to be written…
-
It’s less the app developers, and more the forced frameworks app developers have to work within. Without these walled gardens, this hardware obsolescence wouldn’t really exist, IMO.
-
Yes, the technical (and sometimes legally-protected) inability to control what runs on your machine effectively guarantees some degree of forced obsolescence, as the “latest and greatest” replaces what worked just fine. Indeed, developers essentially have no choice: even the devices they own and develop on are subject to the same forces of basically being coerced into updating/“upgrading” whether they like it or not, thus ensuring the software they develop is dragged along into the newer system requirements as well. Today, I am really starting to feel like all proprietary software is essentially a ticking time bomb as we have no ability to keep it functional after the vendor casts it aside as “obsolete”.
-
-
Or if it is https but a connection attempt to the endpoint fails with a TLS error
This I agree with rejecting. Broken links are broken links, be it a 404 or a TLS error.
If the link is http
This I disagree with, wholeheartedly. Even with my history working at ISRG on Let’s Encrypt, we still found people who did not want to have an HTTPS server. Period. To forcefully ignore that segment of the internet would be foolhardy in my opinion.
Perhaps an alternative could be “automatically replacing HTTP links with HTTPS if it succeeds”. If someone pastes an HTTP link to a site that supports HTTPS, automatically upgrading the link would be nice.
-
we still found people who did not want to have an HTTPS server. Period.
That’s bizarre and inexplicable, but to each their own.
To forcefully ignore that segment of the internet would be foolhardy in my opinion.
Lobsters has no obligation to cater to them and their bizarre insecure decisions either. I am not proposing to force them off the internet, just to not give them link juice from here.
EDIT: I’m not even proposing anything that wild here, Chrome literally already does this, e.g. go to the recent submission https://lobste.rs/s/7lpwis/lisa_source_code_understanding_clascal and click through to the link. Chrome shows an error:
The connection to eschatologist.net is not secure You are seeing this warning because this site does not support HTTPS. Learn more
And they heavily encourage you to not go to that page anyway. At which point most reasonable people should turn back.
-
we still found people who did not want to have an HTTPS server. Period.
That’s bizarre and inexplicable, but to each their own.
What’s inexplicable about not wanting to manage the extra security risk for the server?
And, if we care about client security, we should have a tag
page-requires-jswith a penalty likerant-
What’s inexplicable about not wanting to manage the extra security risk
Do you really consider setting up a basic TLS termination reverse proxy more of a security risk than serving insecure web pages? In that case you are in disagreement with more than half the web, and I don’t see any point in discussing further.
-
For the server, a basic TLS termination server is surely more risk. Heartbleed-class things are less likely with an HTTP server written in a memory-safe language twenty five years ago and getting only bugfixes, not huge mandatory (because TLS versions need to change) changes, since then.
Actually, from a perspective of websites as a population (not from the point of view of configuring a single one), an average HTTP website submitted to Lobste.rs is safer to read than an average HTTPS website. Because an HTTP site will almost surely be old or at least old-style enough to be readable without enabling scripts and without even enabling images (pure-HTML attacks are not that widespread even when someone bothers to intercept), and an HTTPS website has a non-negligible chance of making text Javascript-only and serving Google ads (which are known to let exploits slip from time to time).
-
Interesting, I’ve never heard anyone argue with a straight face before that HTTP sites are actually more secure than HTTPS sites. This is a new one to me, and I’m sure to everyone who has been pushing for HTTPS for more than a decade now. If all the existing arguments for a secure web won’t convince you, then certainly neither will I.
-
They are more secure for the server side, and if Heartbleed has not convinced you that TLS adds risks for the server…
-
I mean this is like conducting a survey to see what 10 dentists think of your toothpaste, finding out that only 3 of them recommend it, then claiming that ‘3 out of 5 dentists recommend our toothpaste’. If you disregard all the other security benefits and look narrowly at only the buffer overflow issue of C-based TLS systems, then sure you can claim that it’s unsafe. You’d also have to ignore options like the Caddy web server, which are written in Go and don’t suffer from C’s memory unsafety issues: https://caddyserver.com/
Written in Go, Caddy offers greater memory safety than servers written in C. A hardened TLS stack powered by the Go standard library serves a significant portion of all Internet traffic.
-
-
-
-
-
-
Lobsters has no obligation to cater to them and their bizarre insecure decisions either
Why is it bizarre? Why not support HTTP links? Pushing folks on way or another will create stubbornness.
Another way of asking it: Why are unencrypted sites not worthy of “link juice” from Lobsters or anywhere else? You seem to have a philosophy about the value of HTTPS that seems slightly incompatible with other folks. I bet you & I broadly agree on many things related to HTTP vs HTTPS, but this aspect is something I don’t understand yet.
-
Why is it bizarre?
What else would you call actively keeping an open vulnerability in the way your website works?
Why not support HTTP links?
Because in the modern web we should want to encourage security and privacy as a first-class requirement instead of an afterthought? Why does Chrome heavily discourage us from visiting http-only links?
Pushing folks on way or another will create stubbornness.
There’s nothing we can do about people who insist on being insecure and unsafe, we just have to move past them.
Another way of asking it: Why are unencrypted sites not worthy of “link juice” from Lobsters
Firstly, because modern browsers will heavily discourage you from visiting those links anyway. So by allowing these submissions we are basically saying ‘We know this is insecure but we don’t care, it’s up to you’. Secondly, Lobsters already filters out content–just check the moderation log. Tons of stories get rejected as off-topic, spam, or scams. If Lobsters is already filtering out content that can potentially annoy or harm its users, automatically filtering out insecure sites is a simple and reasonable step.
or anywhere else?
I didn’t say ‘anywhere else’, I am speaking only about Lobsters here. While the same argument may apply to other cases as well, I would judge that on a case-by-case basis rather than a blanket judgment.
-
Why is it bizarre?
What else would you call actively keeping an open vulnerability in the way your website works?
I suppose it’s possible that some people who have websites actively choose not to use HTTPS, such as by replying “please don’t” to an email message from a managed-hosting provider saying “Your website will be upgraded automatically to HTTPS unless you opt out within the next 30 days.”
Still, I suspect it’s more common for people who have websites that don’t support HTTPS not to be choosing actively not to support it — maybe they set the website up in the 1990s or otherwise before Let’s Encrypt; maybe they don’t understand what HTTPS is or why it would be useful.
Now, I imagine a person who has a website that would be linked from Lobsters is more likely to know what HTTPS is and value it, but they might have a website set up before Let’s Encrypt (or before they understood HTTPS) that they don’t actively maintain; they might have forgotten the website exists; they might be missing or dead.
-
-
I was replying to a person who said that some people actively refused to set up HTTPS on their sites.
In the case that a site doesn’t have HTTPS because it’s not maintained–well, the security risk speaks for itself. It’s an unmaintained site, could be taken over by all sorts of malware.
In the case that the site creator actively refuses to use HTTPS–well, the security risk speaks for itself again. The creator thinks they know better than security practices that have been the norm for more than a decade. You can tell where that will lead.
-
I was replying to a person who said that some people actively refused
Ah, yes, I had forgotten that context by the time I wrote my comment, for which mistake I apologize.
It’s an unmaintained site, could be taken over by all sorts of malware.
I suppose it’s true that the httpd or OS could have a vulnerability that could allow overwriting the website content. I wonder how commonly such attacks succeed in practice for static websites. (On the other hand, if it’s an unmaintained WordPress instance….)
In the case that the site creator actively refuses to use HTTPS–well, the security risk speaks for itself again. The creator thinks they know better than security practices that have been the norm for more than a decade. You can tell where that will lead.
I don’t think it logically follows from “the site creator actively refuses to use HTTPS” that “[t]he creator thinks they know better”. The creator could accept that HTTPS would be an improvement but still decide that they lack the competency and/or time to support it.
-
-
-
-
-
-
-
Or if it is https but a connection attempt to the endpoint fails with a TLS error
… Broken links are broken links, be it a 404 or a TLS error.
TLS error links aren’t the same kind of broken links as 404 links. Generally, in the event of a TLS error, a client that doesn’t care about security can ignore the error [*] and view the content. On the other hand, generally, in the event of a 404, a client can’t view the content no matter what—the server just isn’t showing the content at all.
So, if the grounds for rejecting TLS error links is based solely on this particular argument (i.e. that they’re the same as 404 links), then I don’t agree with rejecting TLS error links.
I agree with the rest of the comment: plain HTTP links should not be rejected.
[*] by clicking through the security warning in web browsers, by using the
-kflag incurl, etc.
-
-
jessicah
5 months ago
|
link
| on:
ocaml-multicore/eio: Effects-based direct-style IO for multicore OCaml
I feel like not using the name eieio was a missed opportunity…
-
You mean the “Enhanced Implementation of Emacs Interpreted Objects”? https://www.gnu.org/software/emacs/manual/html_node/eieio/
-
The original name of the repository I created was https://github.com/ocaml-multicore/eioio to reflect that it was ‘parallel effect-based eio’, but wiser heads (@talex5) prevailed and it was renamed Eio for succinctness ;-)
In my head, I’m still trying to come up with an excuse to have ocaml/aeiou (asynchronous effect-based IO in userspace?)
-
-
Ran into this with Discord’s API a little while back. Everything was fine in the C# backend until I passed data to the frontend in JSON, and numbers silently corrupting. Had to convert them to strings, because JavaScript :-/
-
gpm
6 months ago
|
link
| on:
Sign the open letter about the universal right to install any software on any device
I don’t think that manufacturers should be forced to make it possible to install software on their devices, or even that they should be forced to sell devices to people who won’t agree to a contract saying the won’t install third party software.
I do think that not doing so should void all the patents on the hardware though. The government shouldn’t be letting people use their monopolies on hardware innovations to shove software down users throats. Generally this is known as patent misuse, and it’s a doctrine that should be applied much, much, more broadly (and expanded with legislation).
-
I have an old Apple iPod that hardware and battery wise, stills works perfectly well, but I can’t install or update any software on it because the Apple Store no longer works at all. This effectively turns perfectly good hardware into a paperweight. The apps that I have are still basically functional, until some time as the backend changes, and then it’s an even heavier paperweight.
Similar with an old Microsoft Windows phones. They made some absolutely brilliant hardware, but now the OS for that is dead.
And yet people can not only use extremely ancient hardware, but produce new software and even operating systems due to the more open nature of those platforms. Think 386, Commodore 64, something more exotic like a BeBox, etc.
Any general purpose computing device should be user-unlockable to install whatever the hell we want on it. Put a big nasty warning up, if they must, but our option to choose should be paramount.
-
I think it’s a ridiculous sentiment. Too many electronics are sold as loss leaders with the money made up on software and accessory sales - why would Sony ever make a PS3 if the user could take 30s to install pirated software and the game sales weren’t guaranteed if the console sold?
-
If Sony wants to build a subsidized PS3 with locked down software, they should be free to.
They shouldn’t however be free to also prevent you from building an unsubsidized one and trying to compete with them on the software. That prevents competition on the software, which leads to significant consumer harm.
Incidentally, the original PS3 didn’t have particularly locked down software…
Installing pirated software is illegal regardless of whether or not the PS3s software is locked down.
-
I should have mentioned I’m agreeing with you. It’s ridiculous to force people to allow others to modify their software, it’s also ridiculous to forcibly prevent people from making their own. We should be allowing more people to do things they want to do.
And sure, installing pirated software is illegal - but try telling the 60 million people (mostly teenagers) with new £500 consoles not to download the new Call of Duty.
-
Oh, I think I interpreted your comment to mean the exact opposite of what you meant then. I took “too many” as a justification for why this wouldn’t work, not a moral claim.
I’m not sure pirated software is really that big a substitute for non-pirated software. Amongst people who would otherwise buy it, how many are really going to install sketchy potentially malware infested software from sketchy hard to find internet sites instead? And it shouldn’t even be theoretically possible for multiplayer games with centralized servers (which describes most multiplayer games these days).
-
-
-
-
I’m a European. I think overregulation in the name of “consumer freedoms” is a bad thing. Sorry to disagree with your worldview.
-
-
-
-
I don’t think that manufacturers should be forced to make it possible to install software on their devices,
Is that basically the same as prohibiting manufacturers from adding mechanisms which prevent users from installing software?
or even that they should be forced to sell devices to people who won’t agree to a contract saying the won’t install third party software.
Is that basically the same as withdrawing the legal mechanisms which makes it possible to enforce a contract prohibiting the installation of third party software?
Language of coercion is often used selectively to blame regulators and let companies off the hook.
-
Is that basically the same as prohibiting manufacturers from adding mechanisms which prevent users from installing software?
Well no, it’s a broader definition that includes simply not including affordances. However if you substitute in your version I’m happy to stand behind my comment.
Incidentally, I think your version is also practically impossible to define and legislate.
Is that basically the same as withdrawing the legal mechanisms which makes it possible to enforce a contract prohibiting the installation of third party software?
It’s effectively the same this time, except to the extent that people don’t like lying. Again, I have no problem with substituting in your language and standing behind the claim.
-
-
I mean that it’s not just prohibiting manufacturers from adding mechanisms to prevent users from installing software, but requiring manufacturers to include mechanisms (which I’m referring to as affordances) that allow installing software.
Take a pre-touch iPod for example. It would have been simple for Apple to ship an ipod where there was simply no menu (or command over the USB interface) that said “install this OS”. I sort of assume that ipods did have update mechanisms in reality, but under a different regulatory regime apple could (and probably would) have simply not included that option. Not including any way to tell the device to install an operating system doesn’t involve adding a mechanism preventing installing software, rather, it’s removing things. At the extreme end you could imagine someone literally just not including a wire necessary to write to the storage where the OS lives in the consumer devices.
Legislation requiring that it be possible to install software would say that doing the above is illegal. Legislation that said you can’t make it impossible to install software would say it’s legal, because it was never possible in the first place so no “making” happened.
It would be a bit stranger to do this with a modern smart phone because it means making the part you want to protect un-updateable, but nothing really prohibits it. You could make a smartphone where the OS “just happens” to live on storage that can’t be written to, or have it live on the same storage but “just happen” not to have a general file system API (or any other API) that would let you write to the system folder where it lives.
-
-
I would say that between “change nothing” and “do what the letter asks for” I’d fall on the side of the letter, I just think that expanding patent misuse is a better way to fix the pain points. It’s maybe worth pointing out that in practice no company making high tech hardware would be willing to void all the patents on the hardware, so the non edge case end results are very similar.
I agree that the letter (rightly!) doesn’t get into the details we were discussing, I only did because I couldn’t really agree that the two statements you asked about were the same. I wasn’t intentionally diverging from the language of the letter in my post.
-
-
-
-
-
-
There are a couple things here:
- Users should at least have the right to buy devices that aren’t locked and allow them to install what they want, at prices similar or identical to the locked down devices.
- Actually, users should probably have the right to unlock every single device they own, as a matter of basic individual freedom.
- Our hardware is a big source of pollution, not reusing it until the hardware actually breaks is kind of criminal. And when it does break, we should be able to either replace the broken component, or salvage the working components.
Enabling (1) only requires the existence of enough unlocked alternatives. Which is arguably the case right now with desktops, laptops, and maybe palmtops (for the last one freedom may come at a premium, I don’t know for sure). (2) and (3) however require a global ban. Not even game consoles should be locked down.
(2) in particular highlight the conflict between individual freedom and corporate freedom. I tend to value individual freedom much more (corporations aren’t humans, and there are much fewer corporations than humans).
-
-
I’m a little puzzled. I thought the storage was actually encrypted on these things, and the existence of this bug seems to strongly suggest otherwise unless I’ve severely misunderstood. If swapping out an attacker controlled SIM can get you access to the device storage, it’s not encrypted, right? Is everything here a lie?
-
After accepting my finger, it got stuck on a weird “Pixel is starting…” message, and stayed there until I rebooted it again.
After rebooting the phone, putting in the incorrect PIN 3 times, entering the PUK, and choosing a new PIN, I got to the same “Pixel is starting…” state.
I thought the same thing until I saw these snippets. I believe the “Pixel is starting…” screen is it decrypting the phone using your pin (and failing in this case).
-
To my knowledge an Android phone is encrypted (if you have encryption enabled) when shut off. On boot, you decrypt it using a pin or password.
After the decryption after boot the lock screen is just a simple lock screen. It prevents somebody from accessing your data through the GUI, but the decryption key is loaded somewhere and a dedicated attacker might be able to get the data off a running phone.
There is also a small difference between the two lock screens. The first lock screen (which decrypts the device) has a small additional message telling you to unlock the phone to use all features (translated it from my language, probably other words on native English devices). The lock screens afterwards do not show this message.
I’m really bad at mobile phones though, so my understanding might be wrong. That’s how I understood it when I researched android device encryption.
-
To my knowledge an Android phone is encrypted (if you have encryption enabled) when shut off. On boot, you decrypt it using a pin or password.
For a while now android uses file-based encryption and not full-disk encryption. This means that on boot there is no longer a point where you need to type the password to continue booting. Android’s file-based encryption allows the phone to boot all the way to the lockscreen. However at this point user data is still all encrypted.
After the user types their pin correctly (the first time after boot) user data is decrypted.
And yes you’d be correct that after this point the user data is decrypted and the lockscreen now just acts as a lockscreen.but the decryption key is loaded somewhere and a dedicated attacker might be able to get the data off a running phone.
That’s not entirely correct, at least not for modern phones with dedicated security chips, like the Pixel’s Titan M. The decryption key is ‘stored’ in the Titan M - its very much protected in there. I say ‘stored’ in quotes because its technically a lot more complicated than that (Key Encryption Keys, Weaver tokens, etc).
-
-
I was assuming the physical SIM swap involved a reboot. Maybe that was too generous an assumption.
-
-
I didn’t doubt that. But I thought swapping it would reboot from a cold state, not hold any decryption keys in memory.
-
-
-
-
-
-
What I’m noticing in the description of the RFC process, and which other RFC process like the attempted one in Nix also suffer from, is that there is no clear explanation of how an RFC is rejected. There is a baseline assumption that most proposed changes will eventually be good enough to be accepted.
I think it would help these processes if it were made clear exactly how changes are to be rejected, and that this is included whenever the process is described.
(Obviously slightly off-topic but wanted to get that thought out there.)
-
-
As a full-time C++ dev who actually likes working with C++, I really don’t like language changes like this.
On one hand I agree this syntax is convenient, and subjectively “better” than the existing syntax, and I understand the language needs to grow to stay relevant, but I feel like big syntax changes aren’t productive.
It’s becoming a little ridiculous.
C++ is already big and complicated in the worst way: multiple, incompatible ways to do things, each with nuances and “gotchas” that make them potentially dangerous in certain situations, and there’s usually no clear or obvious way to choose between them, making the language hard to use and teach.
Deprecation doesn’t help, because outside of the big tech companies nobody can afford to go back and update debugged, working code, so most commercial systems just compile in C++11 mode or whatever, and in practice the language only grows.
And as an outside observer to the standards process, there’s no clear direction or design goals for most changes, except that notable people and “experts” in the community proposed them, or somebody found it convenient and had the political savvy to get it adopted. So-and-so at a FAANG read a book about about feature “foo” in language Bar, so now there’s a proposal to cram it into C++.
Meanwhile, learning arbitrary new C++ changes takes away energy from learning new, better designed languages without all of the baggage. C and C++ were designed for an obsolete time in computer history. There are old language that were forward thinking, with modern features, that would be great for new development (cough, Common Lisp :-), but C++ isn’t one of them. By all means, learn new techniques, and apply them in C++, but not every little things needs to be added in.
That said, nobody’s forcing me to use C++, and there’s a lot of new languages to move to, so I guess it’s my own problem…
-
C++ is already big and complicated in the worst way: multiple, incompatible ways to do things, each with nuances and “gotchas” that make them potentially dangerous in certain situations, and there’s usually no clear or obvious way to choose between them, making the language hard to use and teach
this is exactly why something like cppfront is needed, to make bold syntactic and semantic changes that can attempt to regularize the language without being overly shackled to the existing state of affairs. it provides a clean upgrade path for people who are able to use it; for everyone else there’s the more conservative evolution of c++.
-
Languages grow and adapt. C++, Rust, C#, Java, Python, Go, OCaml, Javascript. With research and advances in computing, we are always going to find new, potentially better ways of expressing our programs. And many would argue that C++ isn’t evolving fast enough; I’m generally in that camp. Having to wait for some of the stuff that’s coming in C++23 is a bit frustrating.
A lot of “modern” codebases won’t work with the original versions of a lot of those languages mentioned. Sure, C++ is probably one of the hardest ones to cope with in terms of change I think, but engineering is hard.
-
I only hear about C++ language changes as a cautionary tale.
I don’t hear Java devs complaining it has jumped the shark, and Java is super old by now. C# also managed to survive pretty long and remain coherent. JavaScript got only minor complaints about the dense ES6 syntax, but once everyone got used to it, it’s doing very well. PHP managed to bury a lot of its early mistakes, despite having huge install base and backwards compatibility liability. Rust users welcome its changes with “omg, finally!”. Python3 screwed up, but even they’re getting back on track now.
There’s something unique about C++ that makes it keep adding partial fixes that get more partial fixes every 6 years.
-
I was thinking about that a bit after I posted last night.
So far the history of languages has been to throw them away and create new ones, but maybe the future is to adapt the existing language to the current needs. I still feel like C++ isn’t the best language for that, but it doesn’t hurt to try.
Ironically, Lisp was designed with that kind of growth and evolution in mind, but it never really panned out for other reasons.
-
-
multiple, incompatible ways to do things, each with nuances and “gotchas” that make them potentially dangerous in certain situations, and there’s usually no clear or obvious way to choose between them, making the language hard to use and teach.
This, plus the problem is not just an artifact of C compatibility, it’s an ongoing issue with the recent additions to the C++ standard.
I was very annoyed by the C++11 “universal and uniform initialization” syntax, precisely because it is not universal and uniform. It looks like one faction of the language committee wanted to use the brace initialization syntax for this, and another faction wanted to use the same syntax for aggregate initialization, so they compromised and overloaded the syntax to mean “universal” initialization for some types, and aggregate initialization for other types. So it’s not universal: there’s a gotcha that you need to understand before you can safely use this syntax in generic code.
Ad hoc overloading, where the same syntax means semantically incompatible different things depending on argument types, can be found throughout the language. It makes the language hard to use by creating “gotchas”, and it works against generic programming.
My suggestions for designers of future programming languages: support generic programming.
- Do not use ad-hoc overloading anywhere in the language, because it breaks generic programming.
- However, do use “principled overloading”, where all of the overloaded meanings are semantically compatible and are different implementations of the same algebraic structure, satisfying a common set of axioms. This is important, it’s what makes generic programming possible.
Herb Sutter appears to get this, when he says “generic code demands that consistency” with respect to his proposal, which is intended to be a universal and uniform syntax for a variety of pattern matching. Well, he gets half of it anyway. In his video, he says “do not needlessly use divergent syntax”, because it breaks generic programming.
But, Sutter’s proposal nevertheless introduces ad-hoc overloading. For one, the “is” operator is overloaded for two incommensurate cases:
-
T1 is T2means “the value set of type T1 is a subset of or equal to the value set of T2”. -
V is Tmeans “the value V is contained within the value set of type T”.
If you accept my “value set” metaphor of types, then these two operations correspond to
T1 ⊆ T2andV ∈ Tin set theory. DIfferent operator symbols are used, they aren’t the same thing. Or in the Julia language, which is designed from the ground up for generic programming, these two operations areT1 <: T2andisa(V,T).
-
This mess will continue until parents come to their senses and start giving their children UUIDs as names. When your legal name is “EC691F44-C4D8-48D0-86EF-4A0E7BB8214D”, there’s no reason to ever change it, or your email address. For work email you could even go by a nickname like “EC691F44@example.com” since it’s almost surely unique.
At $WORK, we do something similar at scale. 180k+ users over 500+ applications through an IdP - realistically impossbile to handle name changes manually at our scale. For any given user, they will have a username and email that they are aware of (i.e. jdoe0001 / John.Doe@org.xyz)
However, at the identity level, they actually have different immutable identifiers that are guaranteed to never change:
ea553c28-9db3-4e0c-952d-bcceacb1655ba9362415-7ec7-43a2-ad39-5e095997f553sgyxomlhaisgyxomlhai@p.org.xyzNo application will ever see the ‘human’ attributes like username, but will instead get a combination of attributes. Names can change, usernames and emails can change, but applications will only ever see immutable identifiers in claims from an IdP.
Applications love to use usernames and emails as primary keys, so we enforce application owners to pick one (or more) of the immutable identifiers to consume. No app ever sees anything deemed ‘mutable’ in an OIDC/SAML claim.
Users don’t even know that applications don’t have their ‘human-readable’ email, as the privacyMail is just an alias. But we don’t ever have to deal with the mess that comes with syncing mutable identifiers :)
Isn’t this how most IDPs work? You have an underlying “real” identity and then a bunch of metadata that lets humans differentiate it?
I mean, you kid, but Sweden (and Estonia IIRC) have the concept of a unique identity which is tied to such a system.
In Sweden it’s called a “Personnummer”, it consists of your date of birth and a 4 digit suffix, one used for gender, one for checksum; with an additional number (bringing the total to 5) for an interim number that’s not permanent.
Since they’re guaranteed to be unique they can be used for basically everything and they can be used as primary keys as databases.
You can request a specific personnummer pay some money and it will work, you can request a personnummer sign something which will be forwarded to a BankID phone app for your authorisation.
Works really nicely, honestly.
Encoding gender into the identifier number sounds like a pain for trans people though
You can request a new personnummer with the appropriate gender numeral (IIRC, divisible by 2 means the person considers themselves female), but that leaves enbies in the lurch of course.
You can also request an entirely new personnummer if you need a hidden identity.
The system is from the 1940s and has had to evolve with the times.
Same problems as the similar Finnish one: date of birth can change (apparently recent citizens can turn out to have new and more accurate information about their date of birth) and gender can change. Neither should be part of the immutable identifier.
This was an issue in Sweden too. Other cultures don’t place as much importance on the date of birth as we do, so many people arriving from (IIRC) Syria stated their birthday as the same date in a year, which led to the dates there getting “exhausted”.
The ultimate arbiter of the connection between the numerical identifier and the legal person it’s attached to is Folkbokföringen (population registry), previously part of the local church parish, now part of the tax authority. The “simple” way you get this assigned is through birth. Mom is confirmed to be mom, (dad later), gender is confirmed, birth is reported to the tax authority, and a few days later the personnummer is assigned, and stuff like benefits are routed to the correct recipients. So in a way the number precedes the name, as you’re not required to register a name until 6 months after birth.
That’s really cool, thanks for the information!
If it’s a digit, it could theoretically have room for up to 10 genders… good enough I guess?
I was moreso thinking of being issued a new personnummer, since the closest analog I could compare it to is my SSN, which wasn’t updated to a new number when my name and gender marker were changed. But from the other response, it sounds like they account for changes better in the personnummer system, which makes it less of a roadblock
If you self-identify with the lifelong-tracking-number you’ve been given by the state you might need to deal with that problem first.
This is reductive. If there is a gender component in a number that you cannot change, the gender will be (incorrectly) inferred from the number & automated systems may out you, which increases your surface area for potential discrimination.
Fortunately, looks like you can change it.
Thank you for clarifying the intent of what I was getting at
I can understand why you think it’s like that , but it’s not. The personnummer is simply a numerical representation of your identity. It happens to have a gender component, which is now problematic, just like if you happened to be born outside the country the first digit after the birth date used to be 9, which led to some discrimination.
But fundamentally it’s just a short, numerical, immutable (within limits) representation of who you are.
Using such number as a primary key in your database sounds like a GDPR nightmare. It will end up in logs, URLs and error messages.
There’s also a question of future proofing. What if you start selling to companies in addition to individuals and need to extend your customer registry schema? What Personnummers do you assign to non-persons? Or will you migrate to a new schema, invalidating all existing IDs in the process?
Please just use random integers or GUIDs for this purpose.
Personnummer are now considered to be PII so they should not be used as a primary key (even if that’s been done before).
Note that Sweden’s transparency laws are quite expansive so if you know someone’s personnummer, you basically know their name, and vice versa. GDPR actually restricted these laws.
Companies and other legal persons have a similar number called “organisationsnummer”, used for VAT payments etc.
Estonia’s is pretty much the same (isikukood) — 11 digits which include gender, date of birth, serial number and checksum. Mine was issued post-transition so it has my “current” gender; I’m not sure how (or if) they handle that change.
Interesting choice to encode century (and gender) into the first digit. To me this looks like a better solution than the Swedish (well apart from hardcoding gender) where people born in 1903 and 2003 would share the first “03” digits at the start for standard 10-digit format (nowadays some applications use 12 digits including the century). Estonian numbers won’t have to rollover until around 2150 or so.
Yeah, we have those in Czechia and try to get rid of them in favor of rotating IDs and org-specific IDs to prevent uncontrolled aggregation of personal data.
Anyway, we have 2 duplicates in the old IDs (from what I’ve heard from the guys at the Ministry of Interior). The hospitals ran out of their daily allocation and used next number, hoping for best after delivering the babies. Well, duplicates happened.
Interesting. There was a big debate in the 70s and 80s about how the state was aggregating this data, with laws passed to prevent (say) social services from looking at police databases for criminals. Now the tide has turned, and more and more people are demanding that this can be done to combat benefits fraud.
Hah! Except if you want to move to a different email provider, then you’re stuck once again :p