if its not possible to rewrite it in typescript in a way that is as fast as the go version, that really sheds a bad light on v8 and its performance and begs the question why you should write any non browser code in typescript.
if its not possible to rewrite it in go in a way that is as fast as the assembly version, that really sheds a bad light on go and its performance and begs the question why you should write any code in go.
I’m pretty sure it’s not possible to rewrite it in assembly in a way that makes it 2 times faster than the go version. also go code is as easy to write as typescript code.
software development is about finding a sweet spot and between different languages that are about as easy to write 10 times performance difference is pretty meaningful imo
It’s even worse: not just “one of the top language engineers in the world” but specifically architect of both the language being ported and architect of the language they’re saying it should be ported to.
The fucking presumption, the unmitigated arrogance of some people, woof.
What’s your marketing budget? If you aren’t aligned with the marketing budget havers on this, how do you expect them to treat you when your goals diverge?
See also, fast expiring certificates making democratized CT logs infeasible, DNS over HTTPS consolidating formerly distributed systems on cloudflare. It’s not possible to set up a webpage in 2025 without interacting with a company that has enough money and accountability to untrustworthy governments to be a CA, and that sucks.
HTTPS is cool and all, but I wish there was a usable answer that wasn’t “just centralize the authority.”
Sigh. Lobsters won’t let me post. I must be getting rate limited? It seems a bit ridiculous, I’ve made one post in like… hours. And it just shows me “null” when I post. I need to bug report or something, this is quite a pain and this is going to need to be my last response as dealing with this bug is too frustrating.
See also, fast expiring certificates making democratized CT logs infeasible, DNS over HTTPS consolidating formerly distributed systems on cloudflare.
Can you tell me more about these? I think “infeasible” is not accurate but maybe I’m wrong. I don’t see how DoH consolidates anything as anyone can set up a DoH server.
t’s not possible to set up a webpage in 2025 without interacting with a company that has enough money and accountability to untrustworthy governments to be a CA, and that sucks.
You can definitely set up a webpage in 2025 pretty with HTTPS, especially as you can just issue your own CA certs, which your users are welcome to trust. But if your concern is that a government can exert authority within its jurisdiction I have no idea how you think HTTP is helping you with that or how HTTPS is enabling that specifically. These don’t feel like HTTPS issues, they feel like regulatory issues.
HTTPS is cool and all, but I wish there was a usable answer that wasn’t “just centralize the authority.”
There are numerous, globally distributed CAs, and you can set one up at any time.
Lobsters has been having some issues, I had the same trouble yesterday too.
The CT log thing is something i read on here iirc, basically that CT logs are already pretty enormous and difficult to maintain, if there are 5x as many cert transactions cause they expire in 1/5 the time the only people who will be able to keep them are people with big budgets
I suppose i could set up a DoH server, but the common wisdom is to use somebody else’s, usually cloudflare’s, the fact that something is technically possible doesnt matter in a world where nobody does it.
especially as you can just issue your own CA certs
Are you joking? “please install my CA cert to browse my webpage” may technically count as setting up a web page but the barrier to entry is so high I might as well not. Can iphones even do that?
There are numerous, globally distributed CAs, and you can set one up at any time.
That’s a lot more centralized than “I can do it without involving a third party at all.”
I dunno, maybe I’m just romanticizing the past but I miss being able to publish stuff on the internet without a Big Company helping me.
The CT log thing is something i read on here iirc, basically that CT logs are already pretty enormous and difficult to maintain, if there are 5x as many cert transactions cause they expire in 1/5 the time the only people who will be able to keep them are people with big budgets
Strange but I will have to learn more.
I suppose i could set up a DoH server, but the common wisdom is to use somebody else’s, usually cloudflare’s
Sure, because that’s by far the easiest option and most people don’t really care about centralizing on Cloudflare, but nothing is stopping people from using another DoH.
Are you joking? “please install my CA cert to browse my webpage” may technically count as setting up a web page but the barrier to entry is so high I might as well not. Can iphones even do that?
iPhones being able to do that isn’t really relevant to HTTPS. If you want to say that users should be admins of their own devices, that’s cool too.
As for joking, no I am not. You can create a CA, anyone can. You don’t get to decide who trusts your CA, that would require work. Some companies do that work. Most individuals aren’t interested. That’s why CAs are companies. If you’re saying you want a CA without involving any company, including non-profits that run CAs, then there is in fact an “open” solution - host your own. No one can stop you.
You can run your own internet if you want to. HTTPS is only going to come up when you take on the responsibility of publishing content to the internet that everyone else has to use. No one can stop you from running your own internet.
That’s a lot more centralized than “I can do it without involving a third party at all.”
As opposed to running an HTTP server without a third party at all? I guess technically you could go set up a server at your nearest Starbucks but I think “at all” is a bit hard to come by and always has been. Like I said, if you want to set up a server on your own local network no one is ever going to be able to stop you.
I dunno, maybe I’m just romanticizing the past but I miss being able to publish stuff on the internet without a Big Company helping me.
Which drawbacks? I ask not because I believe there are none, but I’m curious which concern you the most. I’m sympathetic to wanting things and not wanting their consequences haha that’s the tricky thing with life.
HTTPS: I want the authentication properties of HTTPS without being beholden to a semi-centralized and not necessarily trustworthy CA system. All proposed alternatives are, as far as I know, bad.
DNS: I want the convenience of globally unique host names without it depending on a centralized registry. All proposed alternatives are, as far as I know, bad.
These kind of accusations are posts that make me want to spend less on lobsters.
Who knows if it’s planned or accidental obsolescence? Many devices and services outlive their teams by much longer than anticipated. Everyone working in software for a long while has experienced situations like those.
I also find the accusation that HTTPS is leading to broken devices rather wild…
I want to offer a different view: How cool is it that the devices was fixable despite Google’s failure to extend/exchange their certificate. Go, tell your folks that the Chromecast is fixable and help them :)
For me, it’s takes like yours that irritate me. Companies that are some of the largest on the planet don’t need people like you to defend them, to make excuses for them, to try to squelch the frustration directed towards them because they’re either evil or incompetent.
By the way, there is no third option - either they’re evil and intended to force obsolescence upon these devices, or they’re incompetent and didn’t know this was going to happen because of this incompetence.
The world where we’re thinking it’s cool that these devices are fixable tidily neglects the fact that 99% of the people out there will have zero clue how to fix them. That it’s fixable means practically nothing.
For me, it’s takes like yours that irritate me. Companies that are some of the largest on the planet don’t need people like you to defend them, to make excuses for them, to try to squelch the frustration directed towards them because they’re either evil or incompetent.
Who cares? No one is defending Google. People are defending deploying HTTPS as a strategy to improve security. Who cares if it’s Google or anyone else? The person you’re responding to never defends Google, none of this has to do with Google.
By the way, there is no third option - either they’re evil and intended to force obsolescence upon these devices, or they’re incompetent and didn’t know this was going to happen because of this incompetence.
Who cares? Also, there is a very obvious 3rd option - that competent people can make a mistake.
Nothing you’ve said is relevant at all to the assertion that, quoting here:
This is the future the “HTTPS everywhere” crowd wants ;)
Even though you’re quoting me, you must be mistaken - this post is about Google, and my response was about someone who is defending Google’s actions (“Who knows if it’s planned or accidental obsolescence?”).
I haven’t a clue how you can think that a whole post about Google breaking Google devices isn’t about Google…
To the last point, “https everywhere” means things like this can keep being used as an excuse to make fully functional products in to ewaste over and over, and we’re left wondering if the companies responsible are evil or dumb (or both). People pretending to not get the connection aren’t really making a good case for Google not being shit, or for how the “https everywhere” comment is somehow a tangent.
Take what you want from my employment by said company, but I would guess absolutely no-one in private and security has any wish/intention/pressure to not renew a certificate.
I have no insider knowledge about what has happened (nor could I share it if I did! But I really don’t). But I do know that the privacy and security people take their jobs extremely seriously.
This isn’t about who you criticize, I would say the same if you picked the smallest company on earth. This is about the obvious negativity.
This is because the article isn’t “Chromecast isn’t working and the devices all need to go to the trash”.
Someone actually found out why and people replied with instructions how to fix these devices, which is rather brilliant. And all of that despite google’s announcements that it would discontinue it..
This is the future the “HTTPS everywhere” crowd wants ;)
I’m not exactly sure what you meant by that, and even the winky face doesn’t elide your intent and meaning much. I don’t think privacy and security advocates want this at all. I want usable and accessible privacy and security and investment in long term maintenance and usability of products. If that’s what you meant, it reads as a literal attack rather than sarcasm. Poe’s law and all.
Not all privacy and security advocates wanted ‘HTTPS everywhere’. Not all of the ‘HTTPS everywhere’ crowd wanted centralized control of privacy and encryption solutions. But the privacy and security discussion has been captured by corporate interests to an astonishing degree. And I think @gerikson is right to point that out.
Do you seriously think that a future law in the US forcing Let’s Encrypt (or any other CA) to revoke the certificates of any site the government finds objectionable is outside the realms of possibility?
HTTPS everywhere is handing a de facto publishing license to every site that can be revoked at will by those that control the levers of power.
I admit this is orthogonal to the issue at hand. It’s just an example I came up with when brewing some tea in the dinette.
In an https-less world the same people in power can just force ISPs to serve different content for a given domain, or force DNS providers to switch the NS to whatever they want, etc. Or worse, they can maliciously modify the content you want served, subtly.
Only being able to revoke a cert is an improvement.
Holding the threat of cutting off 99% of internet traffic over the head of media companies is a great way to enforce self-censorship. And the best part is that the victim does all the work themselves!
The original sin of HTTPS was wedding it to a centralized CA structure. But then, the drafters of the Weimar constitution also believed everything would turn out fine.
They’ve just explained to you that HTTPS changes nothing about what the government can do to enact censorship. Hostile governments can turn your internet off without any need for HTTPS. In fact, HTTPS directly attempts to mitigate what the government can do with things like CT logs, etc, and we have seen this work. And in the singular instance where HTTPS provides an attack (revoke cert) you can just trust the cert anyways.
edit: Lobsters is basically completely broken for me (anyone else just getting ‘null’ when posting?) so here is my response to the reply to this post. I’m unable to reply otherwise and I’m getting no errors to indicate why. Anyway…
Yeah, “trust the cert anyway” is going to be the fig leaf used to convince a compliant SCOTUS that revoking a certification is not a blatant violation of the 1st amendment. But at least the daily mandatory webcast from Dear Leader will be guaranteed not to be tampered with during transport!
This is getting ridiculous, frankly.
You’ve conveniently ignored everything I’ve said and focused instead of how a ridiculous attack scenario that has an obvious mitigation has 4 words that somehow you’re relating to SCOTUS and 1st amendment rights? Just glossing over that this attack makes almost no sense whatsoever, glossing over that the far easier attacks apply to HTTP at least as well (or often better) as HTTPS, glossing over the fact that even more attacks are viable against HTTP that aren’t viable against HTTPS, glossing over that we’ve seen CT logs actually demonstrate value against government attackers, etc etc etc. But uh, yeah, SCOTUS.
SCOTUS is going to somehow detect that I trusted a certificate? And… this is somehow worse under HTTPS? They can detect my device accepting a certificate but they can’t detect me accessing content over HTTP? Because somehow the government can’t attack HTTP but can attack HTTPS? This just does not make any sense and you’ve done nothing to justify your points. Users have been more than charitable in explaining this to you, even granting that an attack exists on HTTPS but helpfully explaining to you why it makes no sense.
In the near future, on the other side of an American Gleichschaltung, a law is passed requiring CAs to revoke specific certificates when ordered.
If the TLS cert for CNN.com is revoked, users will reach a scary warning page telling the user the site cannot be trusted. Depending on the status of “HTTPS Everywhere”, it might not be able to proceed past this page. But crucially, CNN.com remains up, it might be accessible via HTTP (depending on HSTS settings) and the government has done nothing to impede the publication.
But the end effect is that CNN.com is unreadable for the vast number of visitors. This will make the choice of CNN to tone down criticism of the government very easy to make.
The goal of a modern authoritarian regime is not to obsessively police speech to enforce a single worldview. It’s to make it uneconomical or inconvenient to publish content that will lead to opposition to the regime. Media will parrot government talking points or peddle harmless entertainment. There will be an opposition and it will be “protected” by free speech laws, but in practice accessing its speech online will be hard to impossible for the vast majority of people.
If the USA apparatus decides to censor CNN, revoking TLS cert wouldn’t be the way. It’ll be secret court orders (not unlike recent one British government has sent to Apple), and, should they not comply, apprehension of key staff.
And, even if such cert revocation happened, CNN would be able to get new one within seconds by contacting any other ACME CA, there are even some operating in EEA.
I think your whole argument is misguided, and not aimed at understanding failures of Google, but at lashing at only tangentially related problem space.
And my comment is not defence of Google or Cloudflare, I consider both to be malicious for plethora of reasons.
You’re still thinking like the USSR or China or any totalitarian government. The point isn’t to enforce a particular view. The point is to prevent CNN or any other media organization from publishing anything other than pablum, by threatening their ad revenue stream. They will cover government talking points, entertainment, even happily fake news. Like in Russia, “nothing is true and everything is possible”.
And, even if such cert revocation happened, CNN would be able to get new one within seconds by contacting any other ACME CA, there are even some operating in EEA.
Nothing is preventing the US from only allowing certs from US based issuers. Effectively, if you’re using a mainstream browser, the hypothetical law I have sketched out will also affect root CAs.[1]
I think your whole argument is misguided, and not aimed at understanding failures of Google, but at lashing at only tangentially related problem space.
I proposed a semi-plausible failure mode of the current CA-based certification system and suddenly I’ve gotten more flags than ever before. I find it really interesting.
[1] note that each and every one of these attempts to block access will have quite easy and trivial workarounds. That’s fine, because as stated above, having 100% control of some sort of “truth” is not the point. If nerds and really motivated people can get around a block by installing their own root store or similar, it will just keep them happy to have “cheated the system”. The point is having an atomized audience, incapable of organizing a resistance.
I proposed a semi-plausible failure mode of the current CA-based certification system and suddenly I’ve gotten more flags than ever before. I find it really interesting.
The flags are me and they’re because your posts have been overwhelmingly low quality, consisting of cherry picking, trolling, rhetoric, and failing to engage with anyone’s points. You also never proposed any such attack, other users did you the favor of explaining what attack exists.
The closest thing you’ve come to defining an attack (before others stepped in to hand you one) is this:
Holding the threat of cutting off 99% of internet traffic over the head of media companies
It’s not that interesting why you’re getting flagged. IMO flags should be required to have a reason + should be open, but that’s just me, and that’s why I virtually always add a comment when I flag a post.
This is one of the only posts where you’ve almost come close to saying what you think the actual problem is, which if I very charitably interpret and steel-man on your behalf I can take as essentially “The US will exert power over CAs in order to make it hard for news sites to publish content”. This utterly fails, to be clear (as so many people have pointed out that there are far more attacks on HTTP that would work just as well or infinitely better, and as I have pointed out that we have seen HTTPS explicitly add this threat model and try to address it WITH SUCCESS using CT Logs), but at least with enough effort I can extract a coherent point.
I have around 30 flags right now in these threads (plus some from people who took time off their busy schedule to trawl through older comments for semi-plausible ones to flag). You’re not the only one I have pissed off.[1]
(I actually appreciate you replying to my comments but to be honest I find your replies quite rambling and incoherent. I guess I can take some blame for not fully cosplaying as a Project 2025 lawyer, instead relying on vibes.)
It’s fine, though. I’ve grown disillusioned by the EFF style of encryption boosting[2]. I expect them to fold like a cheap suit if and when the gloves come off.
[1] but I’m still net positive on scores, so there are people on the other side too.
[2] they’ve been hyperfocussed on the threat of government threats to free speech, while giving corporations a free pass. They never really considered corporations taking over the government.
Hm, I see. No, I certainly have not flagged all of your posts or anything, just 2 or 3 that I felt were egregious. I think lobsters should genuinely ban more people for flag abuse, tbh, but such is the way.
It’s interesting that my posts come off as rambly. I suppose I just dislike tree-style conversations and lobsters bugs have made following up extremely annoying as my posts just disappear and show as “null”.
I’ve been getting the “null” response too. There’s nothing in the bug tracker right now, and I don’t have IRC access. Hopefully it will be looked at soon.
As to the flags, people might legitimately feel I’m getting too political.
Yeah, “trust the cert anyway” is going to be the fig leaf used to convince a compliant SCOTUS that revoking a certification is not a blatant violation of the 1st amendment. But at least the daily mandatory webcast from Dear Leader will be guaranteed not to be tampered with during transport!
The point of this hypothetical scenario would be that the threat of certificate revocation would be out in the open, to enforce self-censorship to avoid losing traffic/audience. See my comment here:
I’m not sure any of those are good examples of planned obsolescence. As far as I can tell, they’re all services that didn’t perform very well that Google didn’t want to support, tools that got subsumed into other tools, or ongoing projects that were halted.
I think it’s reasonable to still wish that some of those things were still going, or that they’d been open-sourced in some way so that people could keep them going by themselves, or even that Google themselves had managed them better. But planned obsolescence is quite specifically the idea that you should create things with a limited lifespan so that you can make money by selling their replacements. As far as I can tell, that doesn’t apply to any of those examples.
I get that it’s a tongue in cheek comment, but this is what falls out of “we want our non-https authentication certificates to chain through public roots”.
There is no reason for device authentication to be tied to PKI - it is inherently a private (as in “only relevant to the vendor” , not secret) authentication mechanism so should not be trying to chain through PKI, or PKI-like, roots.
Why is this a hyperbole? It is clear that even an enterprise the size of Google, famous for it’s leetcode-topping talent is unable to manage certificates at scale. This makes it a pretty good point against uncritical deployment of cryptographic solutions.
When Microsoft did that I wasn’t standing embarrassed in front of my family failing to cast cartoons on the TV. So it was their problem, not my problem.
Maybe. I think there are two ways to interpret it - “HTTPS Everywhere” means “literally every place” or it means “everywhere that makes sense, which is the vast majority of places”. But, to me, neither of these implies “you should deploy in a way that isn’t considered and that will completely destroy a product in the future”, it just means that you should very likely be aiming for a reliable, well supported deployment of HTTPS.
I was replying more to the “planned and enforced obsolescence” conspiracy theorizing.
It is true that managing certificates at scale is something not a lot of large organizations seem to be able to pull off, and that’s a legitimate discussion to have… but I didn’t detect any good faith arguments here, just ranting
One time someone hit an assert failed: wtf?! message in one of my libraries and requested I reword it because it looked “unprofessional” when it appeared in their logs.
I was tempted to change it to assert failed: is this software is being used professionally!!11!!11!!!!11111oneone!!111eleven!!!
I guess that wasn’t the most audacious thing but it kinda bothered me they complained like this instead of just fixing the bug so the assert wouldn’t trigger at all lol
Many moons ago I worked at a company what had hundreds of WTF? error messages throughout the code. At one point, a customer complained. The engineer responsible for the messages spend a month updating each message so that it described what the actual error was, along with any suggested fixes.
A bug report that is like “uninformative error message” would probably have been unremarkable, even forgettable. I prolly would have fixed it and moved on. (Indeed, in versions since then, it isn’t an assert at all. It forwards an error code and detailed message through the result object, since that’s so much more useful, just when originally writing it, I didn’t even think about all the failure modes, and certainly not handle them all.)
But the complaint that the company found it unprofessional stuck with me just since it seemed so… superficial and entitled.
Mozilla emphasized that it doesn’t sell or buy data about its users, and that it made the changes because certain jurisdictions define the term “sell” more broadly than others, incorporating the various ways by which a consumer’s personal information changes hands with another party in exchange for monetary or other benefits.
I’m not aware of ways in which my “personal information” could possibly “change hands with another party in exchange for monetary or other benefits” that I personally wouldn’t consider selling my data. I would appreciate it if Mozilla would either bring back the promise that they don’t sell my data (and then keep that promise), or explain exactly how my data “changes hands with another party in exchange for monetary or other benefits” so that I can be the judge of whether or not I consider that acceptable.
Collecting and sharing data with partners to show ads is something which I would consider to be “selling data”, FWIW.
To me, it sounds like Mozilla has realized that it’s breaking their promise to never “sell data” (in ways that its users would consider to be “selling data”) and is trying to weasel their way out of admitting that.
To me, it sounds like Mozilla has realized that it’s breaking their promise to never “sell data” (in ways that its users would consider to be “selling data”) and is trying to weasel their way out of admitting that.
They also have a very low view of the intelligence of their users if they think we’ll actually believe their excuses.
I’m not dogmatic to a fault. I will walk back my criticism if Mozilla can point to one example where “we do X and you wouldn’t describe that as selling your data but it MIGHT possibly run afoul of the CCPA’s definition of selling your data.”
I don’t think X exists. And why should I when the CCPAs definition sounds extremely clear cut to me. The onus is on Mozilla to explain to me how this is more nuanced than I realize. Just give us ONE example.
The Mozilla lawyers say that CCPA and GDPR are not court-tested enough and they are making the ToU so broad such that the terms can prevent a lot of legal attacks. As someone who works for Mozilla, I have decided to trust them. But I can understand some people want to do their own reading…. ¯\_(ツ)_/¯
It must be stressful working for Mozilla and constantly being held to a higher standard.
Despite holding a pitchfork and having lost all faith in Mozilla’s leadership, I have nothing but respect for the people who have made Firefox a viable browser alternative for so long. Sorry you have to deal with this shit :/
Thank you. It would be a more realistic high standard if people contributed instead of complaining.
Filing bugs, finding duplicates, writing docs, everything counts. Not everyone has the necessary level of masochism to deal with a 20 year old C++/Rust/XHTML/CSS/JS codebase and that’s OK.
Heh, it’s not really masochistic if you just focus on an area that’s fairly isolated (for me it was platform stuff: kinetic scrolling for GTK, damage tracking for EGL, gamepad support with evdev, a couple little Wayland bugs, enabling stuff on FreeBSD…) – and what’s really amazing is the tooling, even just the fact that the build is literally just ./mach build and doesn’t take outrageous amounts of time nor memory (well, without LTO).
But I can understand some people want to do their own reading….
I mean, those terms are written for customers, who have to accept them, who are neither lawyers nor Mozilla employees. Legal writing for lawyers but for users to accept is malpractice.
It’s definitely a change in habit. I worked with Mozilla Legal around the GDPR compliance and documentation of crates.io and around the setup around the Foundation and they were very outside focused. Really loved it.
What I did find however is the classic that Mozilla is - curiously - very Californian, and not very international in their management and thinking. Peak of this was me observing someone trying to apply US case law to Germany, which doesn’t have case law.
All that said: I do trust Mozilla, but that’s because I have a privileged inside view through my work on Rust and in Tech Speakers and that can’t be what’s being asked of general users.
HOWEVER, I think it’s also the obligation of people criticizing to not spin the wildest legal theories. FOSS has a lot of armchair lawyers that can’t tell even tell personal information and copyrightable works apart.
license all content you transmit through Firefox to Mozilla (“When you upload or input information through Firefox, you hereby grant us a nonexclusive, royalty-free, worldwide license to use that information to help you navigate, experience, and interact with online content as you indicate with your use of Firefox. -https://www.mozilla.org/en-US/about/legal/terms/firefox)
allow Mozilla to both sell your private information
If you’re already using Firefox, I can confirm that porting your profile over to Librewolf (https://librewolf.net) is relatively painless, and the only issues you’ll encounter are around having the resist fingerprinting setting turned on by default (which you can choose to just disable if you don’t like the trade-offs). I resumed using Firefox in 2016 and just switched away upon this shift in policy, and I do so sadly and begrudgingly, but you’d be crazy to allow Mozilla to cross these lines without switching away.
If you’re a macOS + Littlesnitch user, I can also recommend setting Librewolf to not allow communication to any Mozilla domain other than addons.mozilla.org, just in case.
👋 I respect your opinion and LibreWolf is a fine choice; however, it shares the same problem that all “forks” have and that I thought I made clear in the article…
Developing Firefox costs half a billion per year. There’s overhead in there for sure, but you couldn’t bring that down to something more manageable, like 100 million per year, IMO, without making it completely uncompetitive to Chrome, whose estimate cost exceeds 1 billion per year. The harsh reality is that you’re still using Mozilla’s work and if Mozilla goes under, LibreWolf simply ceases to exist because it’s essentially Firefox + settings. So you’re not really sticking it to the man as much as you’d like.
There are 3 major browser engines left (minus the experiments still in development that nobody uses). All 3 browser engines are, in fact, funded by Google’s Ads and have been for almost the past 2 decades. And any of the forks would become unviable without Apple’s, Google’s or Mozilla’s hard work, which is the reality we are in.
Not complaining much, but I did mention the recent controversy you’re referring to and would’ve preferred comments on what I wrote, on my reasoning, not on the article’s title.
I do what I can and no more, which used to mean occasionally being a Firefox advocate when I could, giving Mozilla as much benefit of the doubt as I could muster, paying for an MDN subscription, and sending some money their way when possible. Now it means temporarily switching to Librewolf, fully acknowledging how unsustainable that is, and waiting for a more sustainable option to come along.
I don’t disagree with the economic realities you mentioned and I don’t think any argument you made is bad or wrong. I’m just coming to a different conclusion: If Firefox can’t take hundreds of millions of dollars from Google every year and turn that into a privacy respecting browser that doesn’t sell my data and doesn’t prohibit me from visiting whatever website I want, then what are we even doing here? I’m sick of this barely lesser of two evils shit. Burn it to the fucking ground.
I think “barely lesser of two evils” is just way off the scale, and I can’t help but feel that it is way over-dramatized.
Also, what about the consequences of having a chrome-only web? Many websites are already “Hyrum’s lawed” to being usable only in Chrome, developers only test for Chrome, the speed of development is basically impossible to follow as is.
Firefox is basically the only thing preventing the most universal platform from becoming a Google-product.
Well there’s one other: Apple. Their hesitance to allow non-Safari browsers on iOS is a bigger bulwark against a Chrome-only web than Firefox at this point IMO.
I’m a bit afraid that the EU is in the process of breaking that down though. If proper Chrome comes over to iOS and it becomes easy to install, I’m certain that Google will start their push to move iOS users over.
I know it’s not exactly the same but Safari is also in the WebKit family and Safari is nether open source nor cross platform nor anywhere close to Firefox in many technical aspects (such as by far having the most functional and sane developer tools of any browser it there).
Pretty much the same here: I used to use Firefox, I have influenced some people in the past to at least give Firefox a shot, some people ended up moving to it from Chrome based on my recommendations. But Mozilla insists on breaking trust roughly every year, so when the ToS came around, there was very little goodwill left and I have permanently switched to LibreWolf.
Using a fork significantly helps my personal short-term peace of mind: whenever Mozilla makes whatever changes they’re planning to make which requires them to have a license to any data I input into Firefox, I trust that I will hear about those changes before LibreWolf incorporates them, and there’s a decent chance that LibreWolf will rip them out and keep them out for a few releases as I assess the situation. If I’m using Firefox directly, there’s a decent probability that I’ll learn about those changes after Firefox updates itself to include them. Hell, for all I know, Firefox is already sending enough telemetry to Mozilla that someone there decided to make money off it and that’s why they removed the “Mozilla will doesn’t and will never sell your data” FAQ item; maybe LibreWolf ripping out telemetry is protecting me against Mozilla right now, I don’t know.
Long term, what I personally do doesn’t matter. The fact that Mozilla has lost so much good-will that long-term Firefox advocates are switching away should be terrifying to Mozilla and citizens of the Web broadly, but my personal actions here have close to 0 effect on that. I could turn into a disingenuous Mozilla shill but I don’t exactly think I’d be able to convince enough people to keep using Firefox to cancel out Mozilla’s efforts to sink their own brand.
If Firefox is just one of three browsers funded by Google which don’t respect user privacy, then what’s the point of it?
People want Firefox and Mozilla to be an alternative to Google’s crap. If they’re not going to be the alternative, instead choosing to copy every terrible idea Google has, then I don’t see why Mozilla is even needed.
Well to be fair to Mozilla, they’re pushing back against some web standard ideas Google has. They’ve come out against things like WebUSB and WebHID for example.
How the heck do they spend that much? At ~20M LoC, they’re spending 25K per line of code a year. While details are hard to find, I think that puts them way above the industry norms.
I’m pretty sure that’s off by 3 orders of magnitude; OP’s figure would be half a US billion, i.e. half a milliard. That means 500M / 20M = 25 $/LOC. Not 25K.
I see your point, but by that same logic, shouldn’t we all then switch to Librewolf? If Firefox’s funding comes from Google, instead of its user base, then even if a significant portion of Firefox’s users switch, it can keep on getting funded, and users who switched can get the privacy non-exploitation they need?
TL;DR 90% of Mozilla’s revenue comes from ad partnerships (Google) and Apple received ca. 19 Bn $ per annum to keep Google as the default search engine.
Where did you get those numbers? Are you referring to the whole effort, (legal, engineering, marketing, administration, etc) ot just development?
That’s an absolutely bonkers amount of money, and while i absolutely believe it, im also kind of curious what other software products are in a similar league
Yeah, that seems like legal butt-covering. If someone in a criminalizing jurisdiction accesses these materials and they try to sue to the browser, Mozilla can say the user violated TOS.
This is just a lie. It’s just a lie. Firefox is gratis, and it’s FLOSS. These stupid paragraphs about legalese are just corporate crap every business of a certain size has to start qualifying so they can’t get their wallet gaped by lawyers in the future. Your first bullet point sucks - you don’t agree to the Acceptable Use Policy to use Firefox, you agree to it when using Mozilla services, i.e. Pocket or whatever. Similarly, your second bulletpoint is completely false, that paragraph doesn’t even exist:
You give Mozilla the rights necessary to operate Firefox. This includes processing your data as we describe in the Firefox Privacy Notice. It also includes a nonexclusive, royalty-free, worldwide license for the purpose of doing as you request with the content you input in Firefox. This does not give Mozilla any ownership in that content.
The text was recently clarified because of the inane outrage over basic legalese. And Mozilla isn’t selling your information. That’s not something they can casually lie about and there’s no reason to lie about it unless they want to face lawsuits from zealous legal types in the future. Why constantly lie to attack Mozilla? Are you being paid to destroy Free Software?
Consciously lying should be against Lobsters rules.
Let’s really look at what’s written here, because either u/altano or u/WilhelmVonWeiner is correct, not both.
The question we want to answer: do we “agree to an acceptable use policy” when we use Firefox? Let’s look in the various terms of service agreements (Terms Of Use, Terms Of Service, Mozilla Accounts Privacy). We see that it has been changed. It originally said:
“When you upload or input information through Firefox, you hereby grant us a nonexclusive, royalty-free, worldwide license to use that information to help you navigate, experience, and interact with online content as you indicate with your use of Firefox.”
Note that this makes no distinction between Firefox as a browser and services offered by Mozilla. The terms did make a distinction between Firefox as distributed by Mozilla and Firefox source code, but that’s another matter. People were outraged, and rightfully so, because you were agreeing to an acceptable use policy to use Firefox, the binary from Mozilla. Period.
That changed to:
“You give Mozilla the rights necessary to operate Firefox. This includes processing your data as we describe in the Firefox Privacy Notice. It also includes a nonexclusive, royalty-free, worldwide license for the purpose of doing as you request with the content you input in Firefox. This does not give Mozilla any ownership in that content.”
Are the legally equivalent, but they’re just using “nicer”, “more acceptable” language? No. The meaning is changed in important ways, and this is probably what you’re referring to when you say, “you don’t agree to the Acceptable Use Policy to use Firefox, you agree to it when using Mozilla services”
However, the current terms still say quite clearly that we agree to the AUP for Mozilla Services when we use Firefox whether or not we use Mozilla Services. The claim that “you don’t agree to the Acceptable Use Policy to use Firefox” is factually incorrect.
So is it OK for u/WilhelmVonWeiner to say that u/altano is lying, and call for censure? No. First, it’s disingenuous for u/WilhelmVonWeiner to pretend that the original wording didn’t exist. Also, the statement, “Similarly, your second bulletpoint is completely false, that paragraph doesn’t even exist:” is plainly false, because we can see that paragraph verbatim here:
So if u/WilhelmVonWeiner is calling someone out for lying, they really shouldn’t lie themselves, or they should afford others enough benefit of the doubt to distinguish between lying and being mistaken. After all, is u/WilhelmVonWeiner lying, or just mistaken here?
I’m all for people venting when someone is clearly in the wrong, but it seems that u/WilhelmVonWeiner is not only accusing others of lying, but is perhaps lying or at very least being incredibly disingenuous themselves.
Oh - and I take exception to this in particular:
“every business of a certain size has to start qualifying so they can’t get their wallet gaped by lawyers”
Being an apologist for large organizations that are behaving poorly is the kind of behavior we expect on Reddit or on the orange site, but not here. We do not want to or should we need to engage with people who do not make good faith arguments.
Consciously lying should be against Lobsters rules.
This is a pretty rude reply so I’m not going to respond to the specifics.
Mozilla has edited their acceptable use policy and terms of service to do damage control and so my exact quotes might not be up anymore, but yeah sure, assume that everyone quoting Mozilla is just a liar instead of that explanation if you want.
Sorry for being rude. It was unnecessary of me and I apologise, I was agitated. I strongly disagree with your assessment of what Mozilla is doing as “damage control” - they are doing what is necessary to legally protect the Mozilla Foundation and Corporation from legal threats by clarifying how they use user data. It is false they are selling your private information. It is false they have a nonexclusive … license to everything you do using Firefox. It is false that you have to agree to the Acceptable Use Policy to use Firefox. It’s misinformation, it’s FUD and it’s going to hurt one of the biggest FLOSS nonprofits and alternate web browsers.
It is false that you have to agree to the Acceptable Use Policy to use Firefox.
So people can judge for them selves, the relevant quote from the previous Terms of Use was:
Your use of Firefox must follow Mozilla’s Acceptable Use Policy, and you agree that you will not use Firefox to infringe anyone’s rights or violate any applicable laws or regulations.
This is a pretty incendiary comment and I would expect any accusation of outright dishonesty to come with evidence that they know they’re wrong. I am not taking a position on who has the facts straight, but I don’t see how you could prove altano is lying. Don’t attribute to malice what can be explained by…simply being incorrect.
FYI this is a change made in response to the recent outrage, the original version of the firefox terms included
Your use of Firefox must follow Mozilla’s Acceptable Use Policy, and you agree that you will not use Firefox to infringe anyone’s rights or violate any applicable laws or regulations.
Your locale is forced to en-US, your timezone is UTC, your system is set to Windows. It will put canvas behind a prompt and randomizes some pixels such that fingerprinting based on rendering is a bit harder. It will also disable using SVG and fonts that you have installed on your systems
Btw, I don’t recommend anyone using resist fingerprinting. This is the “hard mode” that is known to break a lot of pages and has no site-specific settings. Only global on or off. A lot of people turn it on and then end up hating Firefox and switching browsers because their web experience sucks and they don’t know how to turn it off. This is why we now show a rather visible info bar in settings under privacy/security when you turn this on and that’s also why we are working on a new mode that can spoof only specific APIs and only on specific sites. More to come.
Yes, if everyone is running a custom set of spoofs you’d end up being unique again. The intent for the mechanism is for us to be able to experiment and test out a variety of sets before we know what works (in terms of webcompat). In the end, we want everyone to look as uniform as possible
It breaks automatic dark mode and sites don’t remember their zoom setting. Dates are also not always localized correctly. That’s what I’ve noticed so far at least.
Nice review and props for doing the research.
But is it just me, or are all of these horrible value and lukewarm specs at best? 3 cores and 12 GiB RAM at a blistering $100/month? 275 GB drive? Gigabit only? I guess connectivity is good, but do you really need that in most cases? When it’s gigabit only anyway?
You’re not wrong! There are some cheaper prices elsewhere.
However my most direct comparison is to DigitalOcean since I just got finished migrating from there to FullHost. I went from two smaller DO droplets, to one larger VPS on FullHost, and I’m paying about 15% less. With FullHost I have better combined specs, plus they gave me AMD EPYC-Genoa CPUs whereas on DigitalOcean I had pretty low specs on both droplets, likely on overprovisioned metal.
Even on AWS or Google Cloud, once you select a decent processor, NVMe disks, static IPv4, etc. the price is much higher than the attractive sticker price that initially sucked us in.
Fair enough, though both AWS and GCP are regarded as very expensive in the hobbyist circles, as far as I am aware.
For some context check out hetzner dedicated boxes. For $70 US / mo, you can find a machine with 64 GiB ram, an 8 core / 16t cpu and 2x 1TB nvme that will demolish those VPSes in any metric, maybe except reliability as its usually not enterprise grade hardware.
And my personal favourite option is to run a physical machine at home. The build cost amortises pretty well and electricity cost is minimal compared to the prices above. Connectivity can be troublesome, but it’s not too hard to use for instance a dirt-cheap VPS to forward connections over a tunnel if you don’t get a public IP from your ISP.
Yeah. I was thinking the same. I recently went with OVH and their ECO range has some great prices. The hardware is older but the value is still there. They have a handful of Canadian datacenters but I guess they aren’t technically a Canadian provider.
I’m curious to what extent Apple’s hand was forced here. Their stance has consistently been pro-user privacy, and their actions generally reflect that. Was this Apple flipping the table on the U.K. after being asked to do something far worse? (Matthew Green had some commentary on this)
Their hand was 100% forced. The UK demands are fundamentally incompatible with ADP. Unless you’re saying it is an option to just pretend to deliver E2EE while backdooring it?
Isn’t that what they did for Chinese users? Building a custom secret store out of hardware with known local security vulnerabilities and hosting it in Chinese government owned datacenters. But it’s much easier for Apple to tell the UK to suck it up than China.
My bad—my question wasn’t well formulated. The time between the UK’s initial backdoor request and Apple pulling ADP from UK users was surprisingly short. I’m wondering why they had to comply so quickly instead of fighting longer. I don’t think they’d give in unless it was absolutely necessary or something bigger was at risk.
You’re missing the point - if the UK government has a law that says ADP is illegal apple can’t offer it, just like they can’t offer a door-to-door hitman service - they could go to court to fight the law (though in the UK that’s much harder), but while doing so they still can’t offer the service (unless they got some kind of injunction, which - because it’s the uk - is again unlikely).
Simply not offering the service, so UK residents have less data security than anyone else is the solution, is far better than trying to pretend some broken system is in any way secure. Governments need to understand that they don’t get to demand broken encryption and simultaneously pretend they’re not responsible for the security damage it does.
It wasn’t a backdoor “request”, it’s a demand. The UK told Apple they have to do xyz and can’t reveal that they’ve done it. There’s nothing to fight, it’s an order.
The options are (1) backdoor the encryption - thus defeating it for everyone else or (2) do not offer it at all.
Hopefully when the apparent “in future you will be required to turn this off” will come with a message along the lines of “the UK government has required us to store your data in a way that can be read by hackers, monetized by us, and provided to any government agency that requests it - without your knowledge - if you could please enter your password now that would be greatly appreciated”
I will eat my hat if Apple will ever do such a thing. They will say the local regulations require the user to disable it and that’s it. No sarcasm will be employed.
if you offer a service that is actually secure, you’re required to silently downgrade it to a non-secure system and you cannot tell the victims.
Alternatively you do what apple is doing and say “We are not going to offer a system in which we claim certain levels of security that are not possible, or could be actively downgraded in future without user consent or notice solely to support totalitarian governments and incompetent law enforcement”.
The technical capability notice only applies to services you provide, and the existence of that law means that any company operating in the UK that claims to offer secure storage is lying, maybe in future they’d adopt a demand that you not take down any service, but the way to defend against that is to not offer such a service in any country that has such an atrocious human rights record - and while everyone thinks of the US police force when they think of corrupt police, remember the UK police are notorious for violating human rights and the only difference is that they don’t murder people as often.
The UK government’s demand came through a “technical capability notice” under the Investigatory Powers Act (IPA), requiring Apple to create a backdoor that would allow British security officials to access encrypted user data globally.
Yes, if I understand you correctly - as mentioned in the beginning of this article (and reported earlier elsewhere) the UK government asked them to backdoor ADP.
It’s not so popular these days but you can really avoid a lot of strife with a couple of USB hard drives and a bit of routine for rotating them. Doubly so for Apple users where Time Machine is so complete and effective.
Are you suggesting people can just use self-encrypted hard drives as an ADP replacement? That’s not reasonable. ADP is about E2E encrypting data used by most iCloud services, not just files in iCloud Drive. For example, Mail in iCloud mail. Unless your encrypted hard drives also have a suite of software services on top of them that communicate with all your devices, they aren’t a replacement. List of services can be found here: https://support.apple.com/en-us/102651
I assume it’s a mistake that you mention mail? That one fairly obviously has to be handled in cleartext by Apple. I’ve been out of the ecosystem for a few years but doesn’t iPhone sync directly with Macs over USB and LAN for photos, contacts and so on?
But if it sounds like I’m proposing we stop trading off data autonomy at the first whiff of multi-device always-on convenience, then yes that would also be true.
It’s not just “multi-device always-on convenience.” iCloud lets you share a file, send a message, get a reminder, save a bookmark in your browser, store a movie ticket pass, save points on a map, etc. Saying you can replace this with an encrypted hard drive is nuts.
Backing up with iTunes and USB cables is also unnecessarily painful. There is no automated backup. You have to stand there and wait for the passcode prompt to come up every time you want to do a backup, at least on Windows. It is messy and error prone. And if you accidentally hit don’t trust instead of trust even just once by accident, you are in for a world of hurt. Apple has made local backup very painful recently.
Apple has done a great job at making non cloud backups suck which is completely hypocritical given their supposed privacy stance since they own the keys to the cloud backups, so they now own every iOS user’s data (except those using ADP).
I use backup over WiFi. It still requires typing the passphrase (which they have an incentive to keep to push people on iCloud).
I’m using https://imazing.com to do the backups, I don’t remember the hard requirement I had for it but I think it’s because it initiates backups on its own, so the only manual step is the passphrase prompt.
You can customize the initiation conditions like minimum battery, time period.
It’s not the best software ever but works fine as a set it and forget it solution for me.
Time Machine can do encrypted backups to any SMB server and iOS can back up to a Mac (over WiFi) so you can quite easily back up all of your Apple devices without iCloud. The iOS devices periodically sync to the Mac, and the Mac does incremental backups to the SMB server. The Time Machine backups are to an encrypted disk image containing an APFS filesystem on the server, so the server just sees a sparse bundle with a load of files inside for chunks of the disk. You need to back up the encryption key separately if you do this, but it gives you off-site backups.
Btw. I guess we can assume that UK wants similar data access from other cloud providers. So if people store data in some other big cloud and expect it to be encrypted securely, they are quite likely wrong.
And I wonder about smaller cloud setups. I guess UK will go after the largest providers first (Apple, Google, Office365, Backblaze…); but after that they might make the same demands (i.e. “accessing stored data without the victim knowing”) from personal Nextcloud instances?
E2EE doesn’t say a lot about how many ends there are. I suppose the UK gov’t (and many others) are fine if they are one of those ends as well.
In a system that handles both E2EE and storage, that’s painfully simple to do.
My reading of @pgeorgi’s comment is they’re suggesting Google have perhaps stretched the definition of “end-to-end” beyond generally accepted limits. That is, in such a way that if legally challenged Google may respond, in floral legalese, “the number of ‘ends’ were never defined”.
But maybe I’m reading too far :) It’s a plausible theory in any case, albeit conspiratorial in the absence of evidence. Conspiratorial thinking can be a fun and beneficial exercise, sufficiently constrained.
“E2EE with key escrow” would add a miniscule amount of data and complexity but provide a NOBUS interface into the data for whoever owns the escrow key:
A government compels the software provider (say, with a National Security Letter) to encrypt all E2EE keys with a public key provided by the government and send that encrypted data along.
Those encrypted keys are of no use to the software provider, all they can do is pass them along.
The government can decrypt the E2EE data once they get hold of it using the E2EE keys they decrypted after receiving them from the software provider.
If the software provider is the same organization as the storage provider, they can hide the matter even better: for example, increase session id length and encode the encrypted keys in those spare bits in an https header that looks pretty random to begin with. Filter out bits that represent the encrypted key on the server and pass them to the government as they come in.
From everybody’s perspective except those controlling the escrow key (that government), it still looks like a complete E2EE scheme. In particular, the storage provider can’t access the data, so that’s stronger than wire encryption.
Those encrypted keys are so small, relatively speaking, that they won’t necessarily raise red flags in transit or at rest. The only way is a complete audit of the software.
Between “app stores” as preferred delivery mechanism and “auto updates” being applied whenever the distributor wants (or is asked to), at least on platforms like Apple’s/Android that sparked the discussion, you rarely can be sure that you’re running what you audited.
That’s the context of the article, and it’s the reality of most computer users these days.
My important data is air gapped, which sidesteps the entire issue, but that’s far from the reality of most, and so is compiling your own E2EE system software after carefully auditing it, from the firmware and kernel upwards.
You have to wonder if they’ll outlaw encryption entirely. I mean, you would expect the true criminals to simply move to some homegrown system where they encrypt things themselves. It’s only the lazy/dumb criminals they’ll catch with this Apple thing.
This severely reduces the security of passkeys. It makes email access all you need for account access, and it makes passkeys which are not phishable into something that is phishable.
That doesn’t mean it’s a bad idea. It’s probably fine for certain things. Maybe even better than passwords for most things.
In the proposed setup, the thing that is phishable is the magic link, not the passkey. The article’s suggestion downgrades the unphishable passkey into a phishable magic link.
Okay, maybe I’m missing something, but how is a magic link phishable?
The service providers email is not going to be intercepted by the fishing attacker. So the link is always going to point directly to the service provider’s page.
Are you talking about someone phishing to get into the email account?
If it was something like a one-time token, like, please enter this six-digit number, I could see how that would be phishable. But a link is not phishable on its own.
I think you’re just misunderstanding what phishing is. When a person phishes your password they get you to reveal your password to them, usually through some form of social engineering such as tricking you into thinking they are tech support or something.
A magic link is easily phished: the attacker just has to convince you to forward the email to them.
A passkey is not phishable, because an attacker can’t convince you to give it to them.
I would call that more of a tech support scam than phishing. Where do you draw the line? If they can ask you to forward a login email, they can probably ask you to install/activate TeamViewer or something similar… From there they can just ask you to login with the passkey and grab your cookie or something. Or just inject malware and grab the cookie from the chrome/firefox DB. Or, hell, even the passkey private keys themselves.
No matter where you draw the line between confidentiality (or authn/authz) vs availability / recoverability, or, failing open vs failing closed, there will always be tradeoffs. It seems fairly obviously context dependent to me. Are you a large enterprise with 24/7 IT support for your employees? Sure, lock it down to the max, 100% . Are you a “for fun” social media website? Why not make it easier to use and harder to lose access to your account… your users will thank you.
the attacker just has to convince you to forward the email to them.
Let’s note that these emails will typically say something like ‘WARNING: do not share this link with anyone or your account will be compromised’. Sure, even after that a good scammer might get some hapless users to forward theirs. But I’d like to see some examples of that rather than ‘lol’.
User is directed to BADSITE via an email or text, it displays the page GOODSITE would display for lost/no passkey.
User enters their email address in the box to get a magic link.
BADSITE posts this to GOODSITE, which sends the email to user.
BADSITE displays a box asking the user to enter the link from their email.
User enters the link in the box, BADSITE gets a passkey for the user, then redirects them to GOODSITE.
Now, step 4 relies on the user doing the Wrong Thing, and it is easier to do the Right Thing than the Wrong Thing here. But users are used to entering codes that were texted or emailed to them into websites or apps, and honestly, the average user doesn’t know what a URL is.
There are quite a variety of things you can do in the email to funnel users into doing the Right Thing rather than the Wrong Thing that BADSITE told them they needed to do in order to get back into the GOODSITE. But as long as the Wrong Thing is possible, there are a certain number of users that will do the Wrong Thing. Magic links are… harder to phish than passwords, I guess, if you do them right? But definitely phishable.
Theoretically, anything is possible. In practice, it’s much harder to find real-world examples of it happening than it is to make up theoretical scenarios 😉
I’m surprised you’re using this as an example. The article says that Instagram sent the magic link as a text message. You are talking about security and your argument is that magic links sent via SMS are phishable? You do understand how insecure SMS is–right?
Please read my post carefully where I specifically said that the magic link should be emailed. Email offers encryption and the ability to use tags with text descriptions so that the bare link is not visible. Actually go and check Instagram’s emailed magic link, it doesn’t expose the https:// URL. Taking a screenshot of that wouldn’t expose anything to a scammer and in the case that the request was legit, it would also prove that the seller owned the account!
There is no such thing as perfect security. We trade some theoretical security perfection in exchange for ordinary people actually being able to use their accounts comfortably.
something that is phishable.
Doubt. If you message it correctly you should be able to make it very obvious to users that they should never share the magic link with anyone. And, I can understand convincing a hapless user to share an emailed token. But handing over an entire magic link? I’d love to see how scammers are going to phish for that. There’s a reason why magic links are so widely used today. If they were as insecure as you are implying, that would not be the case.
But there’s a fly in the ointment: certain influential tech people really dislike them. According to DHH:
if you sign up for a service on Windows, and you then want to access it on iPhone, you’re going to be stuck (unless you’re so forward thinking as to add a second passkey, somehow, from the iPhone will on the Windows computer!)…
Disclaimer: I work at 1Password
People keep making this case, but this is only true if you cannot export/sync passkeys. There are password managers—1Password and even I think Apple’s Passwords—that will sync passkeys cross-platform. This shouldn’t be an issue in practice. And, yes, you can’t remember a passkey or easily write it down on paper but given the amount of work regular password management already is, “requiring” software to provide good UX isn’t the worst thing IMO.
1P definitely makes this experience better, but it’s certainly not the default experience for most people. There are people in my life who struggle with 2FA, especially around backing up tokens. I have a hard time imagining that I would be able to get them on board with passkeys, much less installing more software to make passkeys’ use easier.
On the contrary, passkeys require zero extra software and vastly simplify the experience for ordinary non-technical people. Now they don’t need to muck around with passwords anymore, they can just tap their finger or scan their face to log in. This is the first genuine usability improvement for online security in at least two decades.
Your post outlines what is essentially a way to coordinate (“sync”) passkeys using magic links. With that, yes, you can use multiple devices to your heart’s content.
Using magic links works in theory and likely in practice, but it isn’t foolproof either. I’ve seen setups where someone hasn’t yet signed into their email on a device or their email client opens up the wrong browser/etc. There’s rough edges with every approach.
My point is simply that the ideal UX is syncing one passkey across devices using, ideally, 1st party software with a great ootb experience. This is already possible. You’re absolutely right that in lieu of that, you could also use magic links as described to work around it.
A ‘foolproof in practice’ auth method doesn’t exist. So we must haggle about what is the best tradeoff between security and UX for the vast majority of end users who are non-technical, non-power users, and will never go for the hassle of maintaining password managers.
Magic Links are a great way to provide additional flexibility in your application’s authentication system. With Passage, you have the ability to create Magic Links that can be delivered in any way you like - custom email templates, in-app chat messages, or anything else you can think of. Embedding Magic Links in your marketing emails, reminder texts, or other mediums can greatly reduce user friction and increase conversion rates.
So we must haggle about what is the best tradeoff between security and UX for the vast majority of end users who are non-technical, non-power users
No. We can let the user decide. Instead, the arrogance with which some people and services (especially big cloud providers) push their agendas is precisely one of the reasons why people (including me) are very hesitant with passkeys. History has made us aware.
As I’ve said many times, for ordinary non-technical people, this is not the kind of decision that they care about nor want to make. Normal people just want secure accounts that are not extremely difficult to use. They are not going to set up password managers. Many don’t even bother to remember passwords; they just log in every time with ‘forgot password’.
For power users like yourself, you can just use a good password manager to store all your passkeys and never have to use magic links at all.
I personally don’t find it productive to engage in discussions about ‘arrogance’ and ‘agendas’. All the options are in front of you, you have complete freedom as a user. No one is locking you into anything. Not sure what ‘history’ you are ‘aware’ of, but if it’s something relevant to this discussion please feel free to make it instead of spreading FUD.
I personally don’t find it productive to engage in discussions about ‘arrogance’ and ‘agendas’. All the options are in front of you, you have complete freedom as a user.
Do I? Last time I checked GitHub forced me into 2FA, for zero increase in security since I already use a password manager, and I stored the second factor in my password manager for convenience.
Yes, but it’s zero increased security for you. For all the GitHub users who use the same password across N different sites, TOTP codes are a massive improvement to their security posture. Which, in turn, is good for everyone when you start to think about the supply-chain security risks.
It’s a 100% indisputable fact of life today that, if you have a user pick a password, some users are going to re-use passwords from other sites and/or use a very weak password. Passkeys bring the advantages of password managers to everyone else: it’s both way more secure because it’s a unique token for a single site (which is also significantly harder to phish for!), and it’s more convenient because it gets filled in for you. And, unlike, say, Chrome’s built-in password manager, it’s not something you can just ignore and do insecurely anyway.
Personally, rolling out passkeys has barely affected me at all (I’ll take a few seconds to set one up in 1Password if given the option on a site). But– hopefully– it’ll raise the bar for security for everyone else, preventing a lot of the actual practical attacks we’ve seen affect ordinary people.
It’s not black and white. Counterexample: person A uses github for their library X, person B relies on X. Now A loses access to their account and gives up. No further security updates for X unless B actively switches. Now you can claim that this is a rare scenario and I would agree.
Still, my feeling is that those pushing for passkeys are actively trying to talk down or hide the negative parts. The same for 2FA/MFA.
Furthermore, I suspect that the increased control and datamining is something those companies really like. That’s why so many companies only require a phone number. Or other data. Google employees dark patterns. When logging in, it ask you for your birthday and does not even allow you to reject just close the question. It seems like you are forced to give it to log in. However, you can actually just close the browser tab and you are already logged in.
Sorry, but these things take a away trust. At least for me, the burden is now on those services to proof that they are not having bad intentions. And right now, it looks to me like they have. Hence, I’m not willing to give them more power.
Well there you go. GitHub requires users to set up security factors, as is their right. And you the user can store the security factors in your favourite password manager, as is your right. Each party in the transaction has all the freedoms it needs to operate.
GitHub requires users to set up security factors, as is their right.
There’s a tension between their rights, and that of their users. I was lucky they even allowed TOTP, because from their UI I could clearly tell they preferred webauthn. And if one day they decide I need to use a passkey with remote attestation, where all the approved providers only accept an app that runs on an unrooted Android or Apple phone?
Call me paranoid, but since that’s currently the best way I know of to actually secure an account for most users, they have a justification for going this route. And then you could say I am totally free to use any other service instead of GitHub… if it wasn’t for the obvious next step: policies of not pulling in code from sources other than properly secured providers, where “properly” means MFA of the kind I’ve just outlined.
Feels like the old freedom/security tradeoff all over again.
You realize that even if passkeys didn’t exist, the policymakers would still exist and find other ways to make and enforce these policies, right? What you are arguing about has nothing to do with passkeys except in the most tangential sense.
What you are arguing about has nothing to do with passkeys except in the most tangential sense.
There is in the standard itself (Webauthn I believe?) support for cryptographic verification of the passkey provider (the entity/software/dongle that generated the key pair). Which means the standard supports remote attestation. While remote attestation has some legitimate uses, putting it right there in the standard facilitates abusive generalisation.
So there’s your tangent: the standard is an enabler, and I don’t like enablers.
So if I understand correctly you don’t like companies that manufacture kitchen knives? Because they are enablers of people who can do bad things with kitchen knives?
Irrelevant for ordinary users, and missing the point. Read my post, with my strategy backing up passkeys is an obsolete way of thinking when you just log in on any new device with a magic link.
So we must haggle about what is the best tradeoff between security and UX for the vast majority of end users who are non-technical, non-power users, and will never go for the hassle of maintaining password managers.
Does this require not providing any alternative for those who do use a password manager? Like, if there’s an alternative, then some non-technical users are gonna use it and get pwned, so we’d better not?
But this is just my design and recommendation. Others can obviously implement whatever they please. I just happen to think that the added complexity would not be worth it.
Oh I agree it’s far the the default experience, and I’d say far from the ideal experience. My early work on 1Password was its onboarding process and I’ve sat in on enough user interviews/user research that I’ll be the first to say there’s plenty users don’t understand.
Frankly, I think that assertion was an overreach. He explained later that RPs (Relying Parties, ie service providers) could block KPXC because it doesn’t properly verify the user when required to:
the lack of identifying passkey provider attestation (which would allow RPs to block you,
That is a choice that RPs can legitimately make for user security reasons. But I don’t see how they can block specific passkey managers by name.
Attestation existing in the protocol at all seems dangerous to me: inevitably, someone will start whitelisting specific providers “for user security” and then users start having to spread passkeys among providers and non-big-tech providers get frozen out.
someone will start whitelisting specific providers “for user security” and then users start having to spread passkeys among providers and non-big-tech providers get frozen out.
It is an allowlist. I have a FIDO2 level 2 token that is certified and not accepted because a-trust blocks it. There is also no browser or software implementation, only specific keys are allowed.
It allows for third party veto in case of missing required security attestation. Security standards sometimes need to be strict. This is no different from sites disabling TLS <1.3 for security reasons.
Can you explain to me how I can configure my TLS library such that it only allows connections from Google implementations of TLS 1.3 running on Android, and blocks any implementations written by someone other than Google?
This would be equivalent to attestation – instead of requiring a correct implementation of an open protocol, attestation requires a specific device or manufacturer.
That’s incorrect. Attention just says what level of verification was done and what the authenticator was. Attention in and of itself doesn’t require anything; it’s inert data. It’s up to each Relying Party (ie service account provider) to decide what attention requirements they want to enforce.
And if you think about it for a second, it’s obvious why. WebAuthn is a web protocol. The web is built on top of open access protocols where anyone is supposed to be able to participate. If passkey SDK providers start recommending that it be locked down to specific hardware, that will quickly break the web. And nobody wants that.
You seem to be projecting your incentives on to me. Like I said earlier, I don’t care either way because I think this ‘problem’ is way overblown and only a theoretical concern. Relying Parties ie account providers don’t have an incentive to go out of their way to block large swathes of potential users over which devices they’re using. That’s a great way to kill business. And in practice most people are using devices which will have certified authenticators anyway.
Close, but it’s actually ‘we reliably verified that the claimed user is the one making the request’. So actually the opposite of ‘not under end-user control’.
we reliably verified that the claimed user is the one making the request
This is advertisement.
We reliably verified which device model (and possibly which firmware revision) claims to have checked that the user intended to use the passkey.
This is probably close to the technical definition.
We are sure the user was forced to use a device where neither data availability nor user identification policies take user’s preferences, needs, and priorities.
Is how the accepted device list for attestations will be implemented 99% of time, and I would like to see the remaining cases.
Like I said previously, I don’t see how a specific passkey manager can get blocked. The attestation just says whether user verification was done or not. It doesn’t say what the password manager is (as far as I know).
“Attestation” sounds like the kind of remote attestation sometimes demanded of some specific services.
For instance, you get hired in this security company, and they mandate a second factor with a USB dongle. The dongle has 2 private keys: one for you, that could be changed or reset at any time, and one for itself, that comes with a certificate that the device had been manufactured by this or that company.
Remote attestation would be that when you plug your key, the IT system not only asks for your key, it also asks your dongle to certificate the public half, and since the dongle is configured to provide certificates only for keys that it generated itself (that’s a promise of the dongle manufacturer), your company knows for sure your private key can’t leave the dongle, and thus you’re really logging in with the dongle.
Now it makes sense for companies, because leaking employee credentials doesn’t just harm the employee, it may harm the company itself. In this case you may not want to rely on the goodwill or conscientiousness of the employee, and just mandate they use the company issued dongle. That is much less of an issue with public-facing services, where when an account is compromise, the damage tend to be confined to that account.
Now replace “dongle” by “ID provider”, point out that GitHub repository or NPM package compromise can easily have far reaching consequences, and you have your foot in the “oligopolies in the name of consumer protection” door.
(You can try it yourself, there is no way to enroll 1password or a similar thing, it needs to be one of those hardware tokens. They even denylist old yubikeys by firmware version)
someone will start whitelisting specific providers “for user security”
That’s not possible at scale. The ‘someone’ would have to go to every Relying Party and get them to accept the whitelist. The decision is up to each Relying Party ie account service provider what attestation/authenticator they will accept. So your bank might decide to accept only certain known and certified ones, while your ecommerce site might accept others.
But again, I think we are getting too bogged down in the weeds here. For the majority of ordinary, non-technical people, who will use their platforms’ built-in passkey management, all this will work completely fine.
Why is it so obvious when something is at least mostly written by (or expanded/rewritten by) AI?
Disclaimer: I get it; some of you out there are Linters’ biggest fans, almost like they’re your favorite band. But to be clear, this is my humble opinion, not a call to arms! So, if you’re feeling feisty about your lint-enthusiasm, remember, it’s all in good fun!
I peeked at the docs and it looks like it has customizable key bindings and themes, but I’m fairly certain I must be missing something.
What does this terminal emulator do that makes it great? Does it unlock new workflows? Is it just fast? Or is customization really that important to people? Links to explanations welcome!
I say this as someone who uses the terminal (with GNU Screen) a lot, but hasn’t experimented with new terminal emulators (because I don’t know why I should—existing performance is fine for me). For the record, I’m a “just use the defaults” kind of user.
Edit: cross-platform is actually an interesting feature I hadn’t thought about. Oh, but maybe no Windows support yet.
You can stop reading this comment if you don’t give a shit about marketing ghostty, but that copy should maybe be more prominent, as it took me a few clicks to find it too.
Also, it still isn’t really a compelling pitch. As someone who uses iTerm and downloaded ghostty to play with it, I couldn’t name one reason for switching to it. Native tabs? I never noticed or cared that iTerm tabs weren’t native. Fast? What’s an example of how I would notice that?
Congrats on the release though! The fact that I, a terminal non-nerd, can’t tell the difference between iTerm and ghostty after the 1.0 release probably means it’s really great.
Fast is effectively how quickly can the terminal actually process the output of whatever applications are writing to it - parsing all the ANSI escapes, newlines, carriage returns, and such to properly update its internal representation of what should be visible on screen.
If this is slow, the application has to just hang out blocked on a write() call until the terminal finishes dealing with it - a very obvious way to notice this is when you cat a really large file how quickly you are able to get your prompt again. Complex TUI apps like text editors with a lot of styling going on are often noticeably more responsive in “fast” terminals, especially when doing things that redraw the whole screen like scrolling.
also iTerm is native: that is, it does use Mac UI APIs for tabs, windows, text rendering, and so on. It’s just that most of the non-ghostty fast terminals (alacritty, kitty, etc.) are not - e.g. kitty just renders tabs with an additional bit of text UI, so it feels more like having tmux built in than the way iTerm or Terminal.app or Ghostty’s tabs work like other Mac apps.
I ran fd . / --color=always > ~/out until I had 1.3GB of fully colorized content (8,455,044 lines; every line has at least a few colour sequences but some many). Ghostty cats it in 12.1s; iTerm2 takes 38.3s.
tree would have spent most of its time in filesystem calls, not waiting on writes to the terminal to complete
the bit that’s nice day to day about being in a fast terminal isn’t really how much faster you can cat a big file, but more how TUI apps have less input lag, especially when doing things that affect large chunks of the screen (like scrolling in editors, or resizing panes in tmux/zellij) but to me its noticeable even in things like fzf’ (I make heavy use of fzf’s ctrl-R replacement for quickly recalling previous commands)
Have you tried to run time tree > /dev/null to see how long it takes without outputting anything to the terminal? I think the vast majority of the time you see taken up is from IO operations related to listing the files on disk.
You could pipe the output of tree into a file and then output that with cat for a better test.
Also I would kind of argue the term “native” is meaningless in the context of Linux. What even is “native” under Linux? Ghostty seems to use gtk, is Qt not native then? What about xlib?
Yes, I address this in the about page I believe. My argument for “native” is that it’ll feel like an idiomatic app and GTK is the default for most large distros that that is a reasonable thing to say (I’d also say QT is native fwiw).
If you reverse the argument it also makes a bit more sense: Ghostty will feel more “native” (with the above definition) compared to Alacritty, Kitty, etc. for most users. It’ll feel closer to Gnome Terminal or whatever your default is for your desktop environment.
Linux Mint | Cinnamon (GTK), MATE (GTK), Xfce (GTK) |
While those are the defaults, most of them also have a KDE spin (and others).
I’m running KDE myself, and anecdotally I see more and more people switching from gnome due to some design choices. I know you don’t have to support KDE but I also think that it’s more precise to say “gnome native” then Linux native.
Thanks. I did eventually find that first link, but most of my confusion was because I couldn’t find much info on the home page, as well as the /docs page. Once I found the menu button in the upper-right corner I was able to find the feature overview and about page—which were much more helpful in figuring out what makes Ghostty interesting.
Native tabs and splits would probably be an upgrade from my current GNU Screen workflow. Ok, maybe I’m getting it now…
Eh, I’m not so sure, you can screen -d -r from a laptop then pull it back to your desktop… never seen a native thing do that. I switch between desktop and laptop a lot, so this kind* of thing matters to me.
i actually also wrote my own terminal emulator, 100% from scratch, including a gnu screen replacement, since (among other things) it drove me nuts that shift+page up wouldn’t scroll up in an attached session and i couldn’t find any way to make that work without replacing basically every part (and it needed to work on Windows too since my laptop runs Windows). But still same ideas.
I might have to check out your terminal emulator :)
Oh, I’m sure it’d annoy you. I fixed what bugs me and implemented what programs I use needed, but didn’t bother with much else. Odds are we overlap on a lot of desired terminal things… but probably not all things. My thing has basically no customization settings either - if I want to change something, I know where the source is! Heck, the makefile literally has hardcoded paths to things on my computer, so it isn’t even likely to build on someone else’s computer!
Although I bet there’s no technical reason we couldn’t have both native split UI and the ability to dis/reconnect.
Yeah, I wrote a longer comment elsewhere in this thread in reply to the ghostty author with some thoughts on it and ideas for how I’d do it. I also learned (after writing that comment) that tmux supports some kind of command protocol with its parent terminal for this purpose and that’s on the ghostty todo list, so perhaps someday they’ll make it work.
I just tried it in xterm and tmux, and it doesn’t work there. That said, tried it in konsole now and it half works, it let me scroll up but not back down. So it is probably reliant on one of those keyboard extension features in the newer terminal emulators (that I’m pretty sure didn’t exist in 2013 when i wrote mine). Also doesn’t work with the mouse wheel at all, though i do see tmux in konsole showing bash command history with the mouse wheel which is different, so sure looks like tmux can rebind that too with probably a couple more lines of config.
In any case, good to see solutions at least becoming available in the mainstream now!
On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one’s intellectual curiosity.
The guidelines are so open-ended it would be impossible to be off-topic, but when most of the front page looks like “WSDA, USDA announce eradication of northern giant hornet from the United States” I think it’s fair to say the site isn’t living up to its name or original intention anymore.
Which is fine, cause I think that’s what their audience wants.
Speaking to the first part: the platform is 30 years old. A very junior dev only knowing about the SPA they are working on or some other narrow slice of the platform is not a problem or a disconnect: it’s a natural consequence of building a platform layer upon layer for many decades. Just because you learned the platform when there was 1 layer and have been keeping up with each layer since doesn’t mean new developers can do that today. Give people time. Help them learn the platform from the ground up. Have patience.
When a developer has been building for the web for 10 years and then still doesn’t know how document requests work, then you should be worried.
Your point is well-taken but your example is behind the times. Web developers with 10 years experience who don’t know how HTTP works is absolutely a thing that happens now.
You can put comments in JSON files if you know they’re going to be read only by a reasonable parser. If you maintain a parser, you can make it accept comments and nothing bad will happen!
There are a lot of comments here that are nitpicking but in my experience this is totally correct. Turborepo, for example, decided to use comments in their config .json file and it’s fine. The world didn’t end. The RFC police didn’t arrest them. There were no casualties.
As far as I can tell, the security risks are around “what if someone implements this incorrectly, then two different parsers could disagree about the presence of a key”. I’m not going to remove that wording, but I will add a footnote mentioning the potential downsides that apply outside the context of config files if you do it wrong.
I was initially confused to see OT lumped in with CRDT because I didn’t realize it tried to be conflict free. I used to work on a p2p app in the 2000s that used change synchronization, in a way that is very similar to OT, but it would only resolve unambiguously correct conflicts. I thought that was OT but I guess not. TIL!
I love the conclusion “Offline editing is a UI/UX problem, not an algorithms problem”
My favorite example of this idea is git. Software developers are so used to git’s (default) theirs/yours merge UX that it’s hard to explain to them that it is IMPOSSIBLE to properly merge source code without the base. In other words: git is solid because it won’t lose data on its own, but its UX demands that you lose the data for it as an unwilling accomplice, and we’re somehow okay with that. No one says “git’s default configuration loses data” simply because it is the UX that loses the data, not the underlying algorithms.
if its not possible to rewrite it in typescript in a way that is as fast as the go version, that really sheds a bad light on v8 and its performance and begs the question why you should write any non browser code in typescript.
lacking nuance imo
if its not possible to rewrite it in go in a way that is as fast as the assembly version, that really sheds a bad light on go and its performance and begs the question why you should write any code in go.
I’m pretty sure it’s not possible to rewrite it in assembly in a way that makes it 2 times faster than the go version. also go code is as easy to write as typescript code.
software development is about finding a sweet spot and between different languages that are about as easy to write 10 times performance difference is pretty meaningful imo
I love the comments from their GitHub discussion on “Why Go?”.
One of the top language engineers in the world makes a decision on which language to use.
Randos on GitHub:
It’s even worse: not just “one of the top language engineers in the world” but specifically architect of both the language being ported and architect of the language they’re saying it should be ported to.
The fucking presumption, the unmitigated arrogance of some people, woof.
Planned and enforced obsolescence via certificates.
This is the future the “HTTPS everywhere” crowd wants ;)
It will be interesting to see if Google fixes this. On the one hand, brand value. On the other, it’s a chance to force purchase of new hardware!
Not me. I want HTTPS Everywhere and I also don’t want this.
What’s your marketing budget? If you aren’t aligned with the marketing budget havers on this, how do you expect them to treat you when your goals diverge?
See also, fast expiring certificates making democratized CT logs infeasible, DNS over HTTPS consolidating formerly distributed systems on cloudflare. It’s not possible to set up a webpage in 2025 without interacting with a company that has enough money and accountability to untrustworthy governments to be a CA, and that sucks.
HTTPS is cool and all, but I wish there was a usable answer that wasn’t “just centralize the authority.”
Sigh. Lobsters won’t let me post. I must be getting rate limited? It seems a bit ridiculous, I’ve made one post in like… hours. And it just shows me “null” when I post. I need to bug report or something, this is quite a pain and this is going to need to be my last response as dealing with this bug is too frustrating.
Can you tell me more about these? I think “infeasible” is not accurate but maybe I’m wrong. I don’t see how DoH consolidates anything as anyone can set up a DoH server.
You can definitely set up a webpage in 2025 pretty with HTTPS, especially as you can just issue your own CA certs, which your users are welcome to trust. But if your concern is that a government can exert authority within its jurisdiction I have no idea how you think HTTP is helping you with that or how HTTPS is enabling that specifically. These don’t feel like HTTPS issues, they feel like regulatory issues.
There are numerous, globally distributed CAs, and you can set one up at any time.
Lobsters has been having some issues, I had the same trouble yesterday too.
The CT log thing is something i read on here iirc, basically that CT logs are already pretty enormous and difficult to maintain, if there are 5x as many cert transactions cause they expire in 1/5 the time the only people who will be able to keep them are people with big budgets
I suppose i could set up a DoH server, but the common wisdom is to use somebody else’s, usually cloudflare’s, the fact that something is technically possible doesnt matter in a world where nobody does it.
Are you joking? “please install my CA cert to browse my webpage” may technically count as setting up a web page but the barrier to entry is so high I might as well not. Can iphones even do that?
That’s a lot more centralized than “I can do it without involving a third party at all.”
I dunno, maybe I’m just romanticizing the past but I miss being able to publish stuff on the internet without a Big Company helping me.
Strange but I will have to learn more.
Sure, because that’s by far the easiest option and most people don’t really care about centralizing on Cloudflare, but nothing is stopping people from using another DoH.
iPhones being able to do that isn’t really relevant to HTTPS. If you want to say that users should be admins of their own devices, that’s cool too.
As for joking, no I am not. You can create a CA, anyone can. You don’t get to decide who trusts your CA, that would require work. Some companies do that work. Most individuals aren’t interested. That’s why CAs are companies. If you’re saying you want a CA without involving any company, including non-profits that run CAs, then there is in fact an “open” solution - host your own. No one can stop you.
You can run your own internet if you want to. HTTPS is only going to come up when you take on the responsibility of publishing content to the internet that everyone else has to use. No one can stop you from running your own internet.
As opposed to running an HTTP server without a third party at all? I guess technically you could go set up a server at your nearest Starbucks but I think “at all” is a bit hard to come by and always has been. Like I said, if you want to set up a server on your own local network no one is ever going to be able to stop you.
What did that look like?
I want the benefits of HTTPS without the drawbacks. I also want the benefits of DNS without the drawbacks.
On the one hand, I am completely sincere about this. On the other, I feel kind of foolish for wanting things without wanting their consequences.
Which drawbacks? I ask not because I believe there are none, but I’m curious which concern you the most. I’m sympathetic to wanting things and not wanting their consequences haha that’s the tricky thing with life.
HTTPS: I want the authentication properties of HTTPS without being beholden to a semi-centralized and not necessarily trustworthy CA system. All proposed alternatives are, as far as I know, bad.
DNS: I want the convenience of globally unique host names without it depending on a centralized registry. All proposed alternatives are, as far as I know, bad.
These kind of accusations are posts that make me want to spend less on lobsters. Who knows if it’s planned or accidental obsolescence? Many devices and services outlive their teams by much longer than anticipated. Everyone working in software for a long while has experienced situations like those. I also find the accusation that HTTPS is leading to broken devices rather wild…
I want to offer a different view: How cool is it that the devices was fixable despite Google’s failure to extend/exchange their certificate. Go, tell your folks that the Chromecast is fixable and help them :)
For me, it’s takes like yours that irritate me. Companies that are some of the largest on the planet don’t need people like you to defend them, to make excuses for them, to try to squelch the frustration directed towards them because they’re either evil or incompetent.
By the way, there is no third option - either they’re evil and intended to force obsolescence upon these devices, or they’re incompetent and didn’t know this was going to happen because of this incompetence.
The world where we’re thinking it’s cool that these devices are fixable tidily neglects the fact that 99% of the people out there will have zero clue how to fix them. That it’s fixable means practically nothing.
Who cares? No one is defending Google. People are defending deploying HTTPS as a strategy to improve security. Who cares if it’s Google or anyone else? The person you’re responding to never defends Google, none of this has to do with Google.
Who cares? Also, there is a very obvious 3rd option - that competent people can make a mistake.
Nothing you’ve said is relevant at all to the assertion that, quoting here:
Even though you’re quoting me, you must be mistaken - this post is about Google, and my response was about someone who is defending Google’s actions (“Who knows if it’s planned or accidental obsolescence?”).
I haven’t a clue how you can think that a whole post about Google breaking Google devices isn’t about Google…
To the last point, “https everywhere” means things like this can keep being used as an excuse to make fully functional products in to ewaste over and over, and we’re left wondering if the companies responsible are evil or dumb (or both). People pretending to not get the connection aren’t really making a good case for Google not being shit, or for how the “https everywhere” comment is somehow a tangent.
Nope, not mistaken. I think my points all stand as-is.
Take what you want from my employment by said company, but I would guess absolutely no-one in private and security has any wish/intention/pressure to not renew a certificate.
I have no insider knowledge about what has happened (nor could I share it if I did! But I really don’t). But I do know that the privacy and security people take their jobs extremely seriously.
Google has form in these matters, and the Chromecast as a brand even has an entry here:
https://killedbygoogle.com/
But in the future I’ll be more polite in criticizing one of the world’s biggest companies so that this place is more welcoming to you.
This isn’t about who you criticize, I would say the same if you picked the smallest company on earth. This is about the obvious negativity.
This is because the article isn’t “Chromecast isn’t working and the devices all need to go to the trash”. Someone actually found out why and people replied with instructions how to fix these devices, which is rather brilliant. And all of that despite google’s announcements that it would discontinue it..
I’m not exactly sure what you meant by that, and even the winky face doesn’t elide your intent and meaning much. I don’t think privacy and security advocates want this at all. I want usable and accessible privacy and security and investment in long term maintenance and usability of products. If that’s what you meant, it reads as a literal attack rather than sarcasm. Poe’s law and all.
Not all privacy and security advocates wanted ‘HTTPS everywhere’. Not all of the ‘HTTPS everywhere’ crowd wanted centralized control of privacy and encryption solutions. But the privacy and security discussion has been captured by corporate interests to an astonishing degree. And I think @gerikson is right to point that out.
Do you seriously think that a future law in the US forcing Let’s Encrypt (or any other CA) to revoke the certificates of any site the government finds objectionable is outside the realms of possibility?
HTTPS everywhere is handing a de facto publishing license to every site that can be revoked at will by those that control the levers of power.
I admit this is orthogonal to the issue at hand. It’s just an example I came up with when brewing some tea in the dinette.
In an https-less world the same people in power can just force ISPs to serve different content for a given domain, or force DNS providers to switch the NS to whatever they want, etc. Or worse, they can maliciously modify the content you want served, subtly.
Only being able to revoke a cert is an improvement.
Am I missing something?
Holding the threat of cutting off 99% of internet traffic over the head of media companies is a great way to enforce self-censorship. And the best part is that the victim does all the work themselves!
The original sin of HTTPS was wedding it to a centralized CA structure. But then, the drafters of the Weimar constitution also believed everything would turn out fine.
They’ve just explained to you that HTTPS changes nothing about what the government can do to enact censorship. Hostile governments can turn your internet off without any need for HTTPS. In fact, HTTPS directly attempts to mitigate what the government can do with things like CT logs, etc, and we have seen this work. And in the singular instance where HTTPS provides an attack (revoke cert) you can just trust the cert anyways.
edit: Lobsters is basically completely broken for me (anyone else just getting ‘null’ when posting?) so here is my response to the reply to this post. I’m unable to reply otherwise and I’m getting no errors to indicate why. Anyway…
This is getting ridiculous, frankly.
You’ve conveniently ignored everything I’ve said and focused instead of how a ridiculous attack scenario that has an obvious mitigation has 4 words that somehow you’re relating to SCOTUS and 1st amendment rights? Just glossing over that this attack makes almost no sense whatsoever, glossing over that the far easier attacks apply to HTTP at least as well (or often better) as HTTPS, glossing over the fact that even more attacks are viable against HTTP that aren’t viable against HTTPS, glossing over that we’ve seen CT logs actually demonstrate value against government attackers, etc etc etc. But uh, yeah, SCOTUS.
SCOTUS is going to somehow detect that I trusted a certificate? And… this is somehow worse under HTTPS? They can detect my device accepting a certificate but they can’t detect me accessing content over HTTP? Because somehow the government can’t attack HTTP but can attack HTTPS? This just does not make any sense and you’ve done nothing to justify your points. Users have been more than charitable in explaining this to you, even granting that an attack exists on HTTPS but helpfully explaining to you why it makes no sense.
Going along with your broken threading
My scenario was hypothetical.
In the near future, on the other side of an American Gleichschaltung, a law is passed requiring CAs to revoke specific certificates when ordered.
If the TLS cert for CNN.com is revoked, users will reach a scary warning page telling the user the site cannot be trusted. Depending on the status of “HTTPS Everywhere”, it might not be able to proceed past this page. But crucially, CNN.com remains up, it might be accessible via HTTP (depending on HSTS settings) and the government has done nothing to impede the publication.
But the end effect is that CNN.com is unreadable for the vast number of visitors. This will make the choice of CNN to tone down criticism of the government very easy to make.
The goal of a modern authoritarian regime is not to obsessively police speech to enforce a single worldview. It’s to make it uneconomical or inconvenient to publish content that will lead to opposition to the regime. Media will parrot government talking points or peddle harmless entertainment. There will be an opposition and it will be “protected” by free speech laws, but in practice accessing its speech online will be hard to impossible for the vast majority of people.
I feel like your entire argument hinges on this and it just isn’t true.
If the USA apparatus decides to censor CNN, revoking TLS cert wouldn’t be the way. It’ll be secret court orders (not unlike recent one British government has sent to Apple), and, should they not comply, apprehension of key staff.
And, even if such cert revocation happened, CNN would be able to get new one within seconds by contacting any other ACME CA, there are even some operating in EEA.
I think your whole argument is misguided, and not aimed at understanding failures of Google, but at lashing at only tangentially related problem space.
And my comment is not defence of Google or Cloudflare, I consider both to be malicious for plethora of reasons.
You’re still thinking like the USSR or China or any totalitarian government. The point isn’t to enforce a particular view. The point is to prevent CNN or any other media organization from publishing anything other than pablum, by threatening their ad revenue stream. They will cover government talking points, entertainment, even happily fake news. Like in Russia, “nothing is true and everything is possible”.
Nothing is preventing the US from only allowing certs from US based issuers. Effectively, if you’re using a mainstream browser, the hypothetical law I have sketched out will also affect root CAs.[1]
I proposed a semi-plausible failure mode of the current CA-based certification system and suddenly I’ve gotten more flags than ever before. I find it really interesting.
[1] note that each and every one of these attempts to block access will have quite easy and trivial workarounds. That’s fine, because as stated above, having 100% control of some sort of “truth” is not the point. If nerds and really motivated people can get around a block by installing their own root store or similar, it will just keep them happy to have “cheated the system”. The point is having an atomized audience, incapable of organizing a resistance.
The flags are me and they’re because your posts have been overwhelmingly low quality, consisting of cherry picking, trolling, rhetoric, and failing to engage with anyone’s points. You also never proposed any such attack, other users did you the favor of explaining what attack exists.
The closest thing you’ve come to defining an attack (before others stepped in to hand you one) is this:
It’s not that interesting why you’re getting flagged. IMO flags should be required to have a reason + should be open, but that’s just me, and that’s why I virtually always add a comment when I flag a post.
This is one of the only posts where you’ve almost come close to saying what you think the actual problem is, which if I very charitably interpret and steel-man on your behalf I can take as essentially “The US will exert power over CAs in order to make it hard for news sites to publish content”. This utterly fails, to be clear (as so many people have pointed out that there are far more attacks on HTTP that would work just as well or infinitely better, and as I have pointed out that we have seen HTTPS explicitly add this threat model and try to address it WITH SUCCESS using CT Logs), but at least with enough effort I can extract a coherent point.
I have around 30 flags right now in these threads (plus some from people who took time off their busy schedule to trawl through older comments for semi-plausible ones to flag). You’re not the only one I have pissed off.[1]
(I actually appreciate you replying to my comments but to be honest I find your replies quite rambling and incoherent. I guess I can take some blame for not fully cosplaying as a Project 2025 lawyer, instead relying on vibes.)
It’s fine, though. I’ve grown disillusioned by the EFF style of encryption boosting[2]. I expect them to fold like a cheap suit if and when the gloves come off.
[1] but I’m still net positive on scores, so there are people on the other side too.
[2] they’ve been hyperfocussed on the threat of government threats to free speech, while giving corporations a free pass. They never really considered corporations taking over the government.
Hm, I see. No, I certainly have not flagged all of your posts or anything, just 2 or 3 that I felt were egregious. I think lobsters should genuinely ban more people for flag abuse, tbh, but such is the way.
It’s interesting that my posts come off as rambly. I suppose I just dislike tree-style conversations and lobsters bugs have made following up extremely annoying as my posts just disappear and show as “null”.
I’ve been getting the “null” response too. There’s nothing in the bug tracker right now, and I don’t have IRC access. Hopefully it will be looked at soon.
As to the flags, people might legitimately feel I’m getting too political.
Genuine question, is this aimed at me?
Nope. Unless you are a lawyer for Project 2025.
Yeah, “trust the cert anyway” is going to be the fig leaf used to convince a compliant SCOTUS that revoking a certification is not a blatant violation of the 1st amendment. But at least the daily mandatory webcast from Dear Leader will be guaranteed not to be tampered with during transport!
Wouldn’t you agree that certificate transparency does a better job detecting this kind of thing than surreptitiously redirecting DNS would?
The point of this hypothetical scenario would be that the threat of certificate revocation would be out in the open, to enforce self-censorship to avoid losing traffic/audience. See my comment here:
https://lobste.rs/s/mxy0si/chromecast_2_s_device_authentication#c_lyenlf
Flagged as trolling. I’m also extremely critical of Google’s killing of various services.
I’m not sure any of those are good examples of planned obsolescence. As far as I can tell, they’re all services that didn’t perform very well that Google didn’t want to support, tools that got subsumed into other tools, or ongoing projects that were halted.
I think it’s reasonable to still wish that some of those things were still going, or that they’d been open-sourced in some way so that people could keep them going by themselves, or even that Google themselves had managed them better. But planned obsolescence is quite specifically the idea that you should create things with a limited lifespan so that you can make money by selling their replacements. As far as I can tell, that doesn’t apply to any of those examples.
Trust Google to not even manage to do planned obsolescence right either…
Please refrain from smirky, inflammatory comments.
I get that it’s a tongue in cheek comment, but this is what falls out of “we want our non-https authentication certificates to chain through public roots”.
There is no reason for device authentication to be tied to PKI - it is inherently a private (as in “only relevant to the vendor” , not secret) authentication mechanism so should not be trying to chain through PKI, or PKI-like, roots.
Hyperbole much? Sometimes an expired certificate is just an expired certificate
Why is this a hyperbole? It is clear that even an enterprise the size of Google, famous for it’s leetcode-topping talent is unable to manage certificates at scale. This makes it a pretty good point against uncritical deployment of cryptographic solutions.
Microsoft let microsoft.com lapse that one time. Should we give up on DNS?
When Microsoft did that I wasn’t standing embarrassed in front of my family failing to cast cartoons on the TV. So it was their problem, not my problem.
(It is still bricked today btw)
No one has ever argued for “uncritical deployment” of any solution, let alone cryptographic ones.
Maybe I’m reading too much into “HTTPS everywhere” then.
Maybe. I think there are two ways to interpret it - “HTTPS Everywhere” means “literally every place” or it means “everywhere that makes sense, which is the vast majority of places”. But, to me, neither of these implies “you should deploy in a way that isn’t considered and that will completely destroy a product in the future”, it just means that you should very likely be aiming for a reliable, well supported deployment of HTTPS.
I was replying more to the “planned and enforced obsolescence” conspiracy theorizing.
It is true that managing certificates at scale is something not a lot of large organizations seem to be able to pull off, and that’s a legitimate discussion to have… but I didn’t detect any good faith arguments here, just ranting
One time someone hit an
assert failed: wtf?!message in one of my libraries and requested I reword it because it looked “unprofessional” when it appeared in their logs.I was tempted to change it to
assert failed: is this software is being used professionally!!11!!11!!!!11111oneone!!111eleven!!!I guess that wasn’t the most audacious thing but it kinda bothered me they complained like this instead of just fixing the bug so the assert wouldn’t trigger at all lol
You’re too generous. I can think of better things to change the logging to…
Many moons ago I worked at a company what had hundreds of
WTF?error messages throughout the code. At one point, a customer complained. The engineer responsible for the messages spend a month updating each message so that it described what the actual error was, along with any suggested fixes.A bug report that is like “uninformative error message” would probably have been unremarkable, even forgettable. I prolly would have fixed it and moved on. (Indeed, in versions since then, it isn’t an assert at all. It forwards an error code and detailed message through the result object, since that’s so much more useful, just when originally writing it, I didn’t even think about all the failure modes, and certainly not handle them all.)
But the complaint that the company found it unprofessional stuck with me just since it seemed so… superficial and entitled.
You should have sent a quote.
I’m not aware of ways in which my “personal information” could possibly “change hands with another party in exchange for monetary or other benefits” that I personally wouldn’t consider selling my data. I would appreciate it if Mozilla would either bring back the promise that they don’t sell my data (and then keep that promise), or explain exactly how my data “changes hands with another party in exchange for monetary or other benefits” so that I can be the judge of whether or not I consider that acceptable.
Collecting and sharing data with partners to show ads is something which I would consider to be “selling data”, FWIW.
To me, it sounds like Mozilla has realized that it’s breaking their promise to never “sell data” (in ways that its users would consider to be “selling data”) and is trying to weasel their way out of admitting that.
They also have a very low view of the intelligence of their users if they think we’ll actually believe their excuses.
Additionally, somehow Mozilla has managed to go 20-25 years without needing to update this wording, so why now?
💯 well put.
I’m not dogmatic to a fault. I will walk back my criticism if Mozilla can point to one example where “we do X and you wouldn’t describe that as selling your data but it MIGHT possibly run afoul of the CCPA’s definition of selling your data.”
I don’t think X exists. And why should I when the CCPAs definition sounds extremely clear cut to me. The onus is on Mozilla to explain to me how this is more nuanced than I realize. Just give us ONE example.
Are there any actual lawyers here who could weigh in?
I’ve largely given up on techies correctly interpreting legalese.
The Mozilla lawyers say that CCPA and GDPR are not court-tested enough and they are making the ToU so broad such that the terms can prevent a lot of legal attacks. As someone who works for Mozilla, I have decided to trust them. But I can understand some people want to do their own reading….
¯\_(ツ)_/¯It must be stressful working for Mozilla and constantly being held to a higher standard.
Despite holding a pitchfork and having lost all faith in Mozilla’s leadership, I have nothing but respect for the people who have made Firefox a viable browser alternative for so long. Sorry you have to deal with this shit :/
Thank you. It would be a more realistic high standard if people contributed instead of complaining.
Filing bugs, finding duplicates, writing docs, everything counts. Not everyone has the necessary level of masochism to deal with a 20 year old C++/Rust/XHTML/CSS/JS codebase and that’s OK.
Heh, it’s not really masochistic if you just focus on an area that’s fairly isolated (for me it was platform stuff: kinetic scrolling for GTK, damage tracking for EGL, gamepad support with evdev, a couple little Wayland bugs, enabling stuff on FreeBSD…) – and what’s really amazing is the tooling, even just the fact that the build is literally just
./mach buildand doesn’t take outrageous amounts of time nor memory (well, without LTO).I mean, those terms are written for customers, who have to accept them, who are neither lawyers nor Mozilla employees. Legal writing for lawyers but for users to accept is malpractice.
It’s definitely a change in habit. I worked with Mozilla Legal around the GDPR compliance and documentation of crates.io and around the setup around the Foundation and they were very outside focused. Really loved it.
What I did find however is the classic that Mozilla is - curiously - very Californian, and not very international in their management and thinking. Peak of this was me observing someone trying to apply US case law to Germany, which doesn’t have case law.
All that said: I do trust Mozilla, but that’s because I have a privileged inside view through my work on Rust and in Tech Speakers and that can’t be what’s being asked of general users.
HOWEVER, I think it’s also the obligation of people criticizing to not spin the wildest legal theories. FOSS has a lot of armchair lawyers that can’t tell even tell personal information and copyrightable works apart.
Fair point. I can agree that this has been blundered in a variety of ways and I’m sorry that it appalled so, so many people.
The ideals of this post are dead. Firefox is neither private nor free. Do not use Firefox in 2025.
Mozilla has done an about face and now demands that Firefox users:
See https://lobste.rs/s/de2ab1/firefox_adds_terms_use for more discussion.
If you’re already using Firefox, I can confirm that porting your profile over to Librewolf (https://librewolf.net) is relatively painless, and the only issues you’ll encounter are around having the resist fingerprinting setting turned on by default (which you can choose to just disable if you don’t like the trade-offs). I resumed using Firefox in 2016 and just switched away upon this shift in policy, and I do so sadly and begrudgingly, but you’d be crazy to allow Mozilla to cross these lines without switching away.
If you’re a macOS + Littlesnitch user, I can also recommend setting Librewolf to not allow communication to any Mozilla domain other than addons.mozilla.org, just in case.
👋 I respect your opinion and LibreWolf is a fine choice; however, it shares the same problem that all “forks” have and that I thought I made clear in the article…
Developing Firefox costs half a billion per year. There’s overhead in there for sure, but you couldn’t bring that down to something more manageable, like 100 million per year, IMO, without making it completely uncompetitive to Chrome, whose estimate cost exceeds 1 billion per year. The harsh reality is that you’re still using Mozilla’s work and if Mozilla goes under, LibreWolf simply ceases to exist because it’s essentially Firefox + settings. So you’re not really sticking it to the man as much as you’d like.
There are 3 major browser engines left (minus the experiments still in development that nobody uses). All 3 browser engines are, in fact, funded by Google’s Ads and have been for almost the past 2 decades. And any of the forks would become unviable without Apple’s, Google’s or Mozilla’s hard work, which is the reality we are in.
Not complaining much, but I did mention the recent controversy you’re referring to and would’ve preferred comments on what I wrote, on my reasoning, not on the article’s title.
I do what I can and no more, which used to mean occasionally being a Firefox advocate when I could, giving Mozilla as much benefit of the doubt as I could muster, paying for an MDN subscription, and sending some money their way when possible. Now it means temporarily switching to Librewolf, fully acknowledging how unsustainable that is, and waiting for a more sustainable option to come along.
I don’t disagree with the economic realities you mentioned and I don’t think any argument you made is bad or wrong. I’m just coming to a different conclusion: If Firefox can’t take hundreds of millions of dollars from Google every year and turn that into a privacy respecting browser that doesn’t sell my data and doesn’t prohibit me from visiting whatever website I want, then what are we even doing here? I’m sick of this barely lesser of two evils shit. Burn it to the fucking ground.
I think “barely lesser of two evils” is just way off the scale, and I can’t help but feel that it is way over-dramatized.
Also, what about the consequences of having a chrome-only web? Many websites are already “Hyrum’s lawed” to being usable only in Chrome, developers only test for Chrome, the speed of development is basically impossible to follow as is.
Firefox is basically the only thing preventing the most universal platform from becoming a Google-product.
Well there’s one other: Apple. Their hesitance to allow non-Safari browsers on iOS is a bigger bulwark against a Chrome-only web than Firefox at this point IMO.
I’m a bit afraid that the EU is in the process of breaking that down though. If proper Chrome comes over to iOS and it becomes easy to install, I’m certain that Google will start their push to move iOS users over.
I know it’s not exactly the same but Safari is also in the WebKit family and Safari is nether open source nor cross platform nor anywhere close to Firefox in many technical aspects (such as by far having the most functional and sane developer tools of any browser it there).
Pretty much the same here: I used to use Firefox, I have influenced some people in the past to at least give Firefox a shot, some people ended up moving to it from Chrome based on my recommendations. But Mozilla insists on breaking trust roughly every year, so when the ToS came around, there was very little goodwill left and I have permanently switched to LibreWolf.
Using a fork significantly helps my personal short-term peace of mind: whenever Mozilla makes whatever changes they’re planning to make which requires them to have a license to any data I input into Firefox, I trust that I will hear about those changes before LibreWolf incorporates them, and there’s a decent chance that LibreWolf will rip them out and keep them out for a few releases as I assess the situation. If I’m using Firefox directly, there’s a decent probability that I’ll learn about those changes after Firefox updates itself to include them. Hell, for all I know, Firefox is already sending enough telemetry to Mozilla that someone there decided to make money off it and that’s why they removed the “Mozilla will doesn’t and will never sell your data” FAQ item; maybe LibreWolf ripping out telemetry is protecting me against Mozilla right now, I don’t know.
Long term, what I personally do doesn’t matter. The fact that Mozilla has lost so much good-will that long-term Firefox advocates are switching away should be terrifying to Mozilla and citizens of the Web broadly, but my personal actions here have close to 0 effect on that. I could turn into a disingenuous Mozilla shill but I don’t exactly think I’d be able to convince enough people to keep using Firefox to cancel out Mozilla’s efforts to sink their own brand.
If Firefox is just one of three browsers funded by Google which don’t respect user privacy, then what’s the point of it?
People want Firefox and Mozilla to be an alternative to Google’s crap. If they’re not going to be the alternative, instead choosing to copy every terrible idea Google has, then I don’t see why Mozilla is even needed.
Well to be fair to Mozilla, they’re pushing back against some web standard ideas Google has. They’ve come out against things like WebUSB and WebHID for example.
How the heck do they spend that much? At ~20M LoC, they’re spending 25K per line of code a year. While details are hard to find, I think that puts them way above the industry norms.
I’m pretty sure that’s off by 3 orders of magnitude; OP’s figure would be half a US billion, i.e. half a milliard. That means 500M / 20M = 25 $/LOC. Not 25K.
I see your point, but by that same logic, shouldn’t we all then switch to Librewolf? If Firefox’s funding comes from Google, instead of its user base, then even if a significant portion of Firefox’s users switch, it can keep on getting funded, and users who switched can get the privacy non-exploitation they need?
I gathered some numbers on that here: https://untested.sonnet.io/notes/defaults-matter-dont-assume-consent/#h-dollar510000000
TL;DR 90% of Mozilla’s revenue comes from ad partnerships (Google) and Apple received ca. 19 Bn $ per annum to keep Google as the default search engine.
Where did you get those numbers? Are you referring to the whole effort, (legal, engineering, marketing, administration, etc) ot just development?
That’s an absolutely bonkers amount of money, and while i absolutely believe it, im also kind of curious what other software products are in a similar league
doesn’t seem like a particularly grave concern to me
That page says “Services”. Does it apply to Firefox or the VPN?
The sexuality and violence thing I suspect is so that they are covered for use in Saudi Arabia and Missouri.
Yeah, that seems like legal butt-covering. If someone in a criminalizing jurisdiction accesses these materials and they try to sue to the browser, Mozilla can say the user violated TOS.
i assume it applies mostly to Bugzilla / Mozilla Connect / Phabricator / etc
This is just a lie. It’s just a lie. Firefox is gratis, and it’s FLOSS. These stupid paragraphs about legalese are just corporate crap every business of a certain size has to start qualifying so they can’t get their wallet gaped by lawyers in the future. Your first bullet point sucks - you don’t agree to the Acceptable Use Policy to use Firefox, you agree to it when using Mozilla services, i.e. Pocket or whatever. Similarly, your second bulletpoint is completely false, that paragraph doesn’t even exist:
The text was recently clarified because of the inane outrage over basic legalese. And Mozilla isn’t selling your information. That’s not something they can casually lie about and there’s no reason to lie about it unless they want to face lawsuits from zealous legal types in the future. Why constantly lie to attack Mozilla? Are you being paid to destroy Free Software?
Consciously lying should be against Lobsters rules.
Let’s really look at what’s written here, because either u/altano or u/WilhelmVonWeiner is correct, not both.
The question we want to answer: do we “agree to an acceptable use policy” when we use Firefox? Let’s look in the various terms of service agreements (Terms Of Use, Terms Of Service, Mozilla Accounts Privacy). We see that it has been changed. It originally said:
“When you upload or input information through Firefox, you hereby grant us a nonexclusive, royalty-free, worldwide license to use that information to help you navigate, experience, and interact with online content as you indicate with your use of Firefox.”
Note that this makes no distinction between Firefox as a browser and services offered by Mozilla. The terms did make a distinction between Firefox as distributed by Mozilla and Firefox source code, but that’s another matter. People were outraged, and rightfully so, because you were agreeing to an acceptable use policy to use Firefox, the binary from Mozilla. Period.
That changed to:
“You give Mozilla the rights necessary to operate Firefox. This includes processing your data as we describe in the Firefox Privacy Notice. It also includes a nonexclusive, royalty-free, worldwide license for the purpose of doing as you request with the content you input in Firefox. This does not give Mozilla any ownership in that content.”
Are the legally equivalent, but they’re just using “nicer”, “more acceptable” language? No. The meaning is changed in important ways, and this is probably what you’re referring to when you say, “you don’t agree to the Acceptable Use Policy to use Firefox, you agree to it when using Mozilla services”
However, the current terms still say quite clearly that we agree to the AUP for Mozilla Services when we use Firefox whether or not we use Mozilla Services. The claim that “you don’t agree to the Acceptable Use Policy to use Firefox” is factually incorrect.
So is it OK for u/WilhelmVonWeiner to say that u/altano is lying, and call for censure? No. First, it’s disingenuous for u/WilhelmVonWeiner to pretend that the original wording didn’t exist. Also, the statement, “Similarly, your second bulletpoint is completely false, that paragraph doesn’t even exist:” is plainly false, because we can see that paragraph verbatim here:
https://www.mozilla.org/en-US/about/legal/terms/firefox/
So if u/WilhelmVonWeiner is calling someone out for lying, they really shouldn’t lie themselves, or they should afford others enough benefit of the doubt to distinguish between lying and being mistaken. After all, is u/WilhelmVonWeiner lying, or just mistaken here?
I’m all for people venting when someone is clearly in the wrong, but it seems that u/WilhelmVonWeiner is not only accusing others of lying, but is perhaps lying or at very least being incredibly disingenuous themselves.
Oh - and I take exception to this in particular:
“every business of a certain size has to start qualifying so they can’t get their wallet gaped by lawyers”
Being an apologist for large organizations that are behaving poorly is the kind of behavior we expect on Reddit or on the orange site, but not here. We do not want to or should we need to engage with people who do not make good faith arguments.
This is a pretty rude reply so I’m not going to respond to the specifics.
Mozilla has edited their acceptable use policy and terms of service to do damage control and so my exact quotes might not be up anymore, but yeah sure, assume that everyone quoting Mozilla is just a liar instead of that explanation if you want.
EDIT:
https://blog.mozilla.org/en/products/firefox/update-on-terms-of-use/
Sorry for being rude. It was unnecessary of me and I apologise, I was agitated. I strongly disagree with your assessment of what Mozilla is doing as “damage control” - they are doing what is necessary to legally protect the Mozilla Foundation and Corporation from legal threats by clarifying how they use user data. It is false they are selling your private information. It is false they have a nonexclusive … license to everything you do using Firefox. It is false that you have to agree to the Acceptable Use Policy to use Firefox. It’s misinformation, it’s FUD and it’s going to hurt one of the biggest FLOSS nonprofits and alternate web browsers.
So people can judge for them selves, the relevant quote from the previous Terms of Use was:
Source: http://archive.today/btoQM
The updated terms make no mention of the Acceptable Use Policy.
This is a pretty incendiary comment and I would expect any accusation of outright dishonesty to come with evidence that they know they’re wrong. I am not taking a position on who has the facts straight, but I don’t see how you could prove altano is lying. Don’t attribute to malice what can be explained by…simply being incorrect.
that’s not binding to firefox. that’s binding to mozilla services like websites and other services. https://www.mozilla.org/en-US/about/legal/terms/mozilla/ links to the acceptable use page for instance. whereas the firefox one does not. https://www.mozilla.org/en-US/about/legal/terms/firefox/
firefox is fine. your other points are also largely incorrect.
FYI this is a change made in response to the recent outrage, the original version of the firefox terms included
Which has now been removed.
What are the trade-offs for resisting fingerprinting? Does it disable certain CSS features, or?
Your locale is forced to en-US, your timezone is UTC, your system is set to Windows. It will put canvas behind a prompt and randomizes some pixels such that fingerprinting based on rendering is a bit harder. It will also disable using SVG and fonts that you have installed on your systems
Btw, I don’t recommend anyone using resist fingerprinting. This is the “hard mode” that is known to break a lot of pages and has no site-specific settings. Only global on or off. A lot of people turn it on and then end up hating Firefox and switching browsers because their web experience sucks and they don’t know how to turn it off. This is why we now show a rather visible info bar in settings under privacy/security when you turn this on and that’s also why we are working on a new mode that can spoof only specific APIs and only on specific sites. More to come.
Now that I know about it, I’m really looking forward to the new feature!
I’m using CanvasBlocker but its performance and UX could use some love.
This is the kind of thing Mozilla still does that sets it very far appart from the rest. Thanks!
heh, I wonder how many bits of entropy will be there in roughly “which of the spoofs are enabled”? :D
Yes, if everyone is running a custom set of spoofs you’d end up being unique again. The intent for the mechanism is for us to be able to experiment and test out a variety of sets before we know what works (in terms of webcompat). In the end, we want everyone to look as uniform as possible
It breaks automatic dark mode and sites don’t remember their zoom setting. Dates are also not always localized correctly. That’s what I’ve noticed so far at least.
Nice review and props for doing the research. But is it just me, or are all of these horrible value and lukewarm specs at best? 3 cores and 12 GiB RAM at a blistering $100/month? 275 GB drive? Gigabit only? I guess connectivity is good, but do you really need that in most cases? When it’s gigabit only anyway?
You’re not wrong! There are some cheaper prices elsewhere.
However my most direct comparison is to DigitalOcean since I just got finished migrating from there to FullHost. I went from two smaller DO droplets, to one larger VPS on FullHost, and I’m paying about 15% less. With FullHost I have better combined specs, plus they gave me AMD EPYC-Genoa CPUs whereas on DigitalOcean I had pretty low specs on both droplets, likely on overprovisioned metal.
Even on AWS or Google Cloud, once you select a decent processor, NVMe disks, static IPv4, etc. the price is much higher than the attractive sticker price that initially sucked us in.
Fair enough, though both AWS and GCP are regarded as very expensive in the hobbyist circles, as far as I am aware.
For some context check out hetzner dedicated boxes. For $70 US / mo, you can find a machine with 64 GiB ram, an 8 core / 16t cpu and 2x 1TB nvme that will demolish those VPSes in any metric, maybe except reliability as its usually not enterprise grade hardware.
And my personal favourite option is to run a physical machine at home. The build cost amortises pretty well and electricity cost is minimal compared to the prices above. Connectivity can be troublesome, but it’s not too hard to use for instance a dirt-cheap VPS to forward connections over a tunnel if you don’t get a public IP from your ISP.
These seem crazy expensive to me too, but do note the prices are in CAD. $100 CAD = $70 USD atm.
It’s funny that when I am looking at Canadian companies for hosting they often are in USD and it is equally irksome :P.
Yeah. I was thinking the same. I recently went with OVH and their ECO range has some great prices. The hardware is older but the value is still there. They have a handful of Canadian datacenters but I guess they aren’t technically a Canadian provider.
I’m curious to what extent Apple’s hand was forced here. Their stance has consistently been pro-user privacy, and their actions generally reflect that. Was this Apple flipping the table on the U.K. after being asked to do something far worse? (Matthew Green had some commentary on this)
Their hand was 100% forced. The UK demands are fundamentally incompatible with ADP. Unless you’re saying it is an option to just pretend to deliver E2EE while backdooring it?
Isn’t that what they did for Chinese users? Building a custom secret store out of hardware with known local security vulnerabilities and hosting it in Chinese government owned datacenters. But it’s much easier for Apple to tell the UK to suck it up than China.
Apparently the UK did not just require access to UK accounts (which they will have with the removal of E2E in the UK) but direct global access.
My bad—my question wasn’t well formulated. The time between the UK’s initial backdoor request and Apple pulling ADP from UK users was surprisingly short. I’m wondering why they had to comply so quickly instead of fighting longer. I don’t think they’d give in unless it was absolutely necessary or something bigger was at risk.
You’re missing the point - if the UK government has a law that says ADP is illegal apple can’t offer it, just like they can’t offer a door-to-door hitman service - they could go to court to fight the law (though in the UK that’s much harder), but while doing so they still can’t offer the service (unless they got some kind of injunction, which - because it’s the uk - is again unlikely).
Simply not offering the service, so UK residents have less data security than anyone else is the solution, is far better than trying to pretend some broken system is in any way secure. Governments need to understand that they don’t get to demand broken encryption and simultaneously pretend they’re not responsible for the security damage it does.
That’s fair. I’m
probablydefinitely overstating Apple’s ideological ability to say just “nah fam”.And shareholders aren’t usually keen on exiting entire markets.
It wasn’t a backdoor “request”, it’s a demand. The UK told Apple they have to do xyz and can’t reveal that they’ve done it. There’s nothing to fight, it’s an order.
The options are (1) backdoor the encryption - thus defeating it for everyone else or (2) do not offer it at all.
Hopefully when the apparent “in future you will be required to turn this off” will come with a message along the lines of “the UK government has required us to store your data in a way that can be read by hackers, monetized by us, and provided to any government agency that requests it - without your knowledge - if you could please enter your password now that would be greatly appreciated”
I will eat my hat if Apple will ever do such a thing. They will say the local regulations require the user to disable it and that’s it. No sarcasm will be employed.
That would be contravening the technical capability notice which requires the provider to keep any actions secret.
No. That’s literally the entire point.
if you offer a service that is actually secure, you’re required to silently downgrade it to a non-secure system and you cannot tell the victims.
Alternatively you do what apple is doing and say “We are not going to offer a system in which we claim certain levels of security that are not possible, or could be actively downgraded in future without user consent or notice solely to support totalitarian governments and incompetent law enforcement”.
The technical capability notice only applies to services you provide, and the existence of that law means that any company operating in the UK that claims to offer secure storage is lying, maybe in future they’d adopt a demand that you not take down any service, but the way to defend against that is to not offer such a service in any country that has such an atrocious human rights record - and while everyone thinks of the US police force when they think of corrupt police, remember the UK police are notorious for violating human rights and the only difference is that they don’t murder people as often.
oof, demanding global access is wild.
Yes, if I understand you correctly - as mentioned in the beginning of this article (and reported earlier elsewhere) the UK government asked them to backdoor ADP.
It’s not so popular these days but you can really avoid a lot of strife with a couple of USB hard drives and a bit of routine for rotating them. Doubly so for Apple users where Time Machine is so complete and effective.
Are you suggesting people can just use self-encrypted hard drives as an ADP replacement? That’s not reasonable. ADP is about E2E encrypting data used by most iCloud services, not just files in iCloud Drive. For example, Mail in iCloud mail. Unless your encrypted hard drives also have a suite of software services on top of them that communicate with all your devices, they aren’t a replacement. List of services can be found here: https://support.apple.com/en-us/102651
I assume it’s a mistake that you mention mail? That one fairly obviously has to be handled in cleartext by Apple. I’ve been out of the ecosystem for a few years but doesn’t iPhone sync directly with Macs over USB and LAN for photos, contacts and so on?
But if it sounds like I’m proposing we stop trading off data autonomy at the first whiff of multi-device always-on convenience, then yes that would also be true.
Yes, sorry, I meant Messages and not Mail.
It’s not just “multi-device always-on convenience.” iCloud lets you share a file, send a message, get a reminder, save a bookmark in your browser, store a movie ticket pass, save points on a map, etc. Saying you can replace this with an encrypted hard drive is nuts.
Backing up with iTunes and USB cables is also unnecessarily painful. There is no automated backup. You have to stand there and wait for the passcode prompt to come up every time you want to do a backup, at least on Windows. It is messy and error prone. And if you accidentally hit don’t trust instead of trust even just once by accident, you are in for a world of hurt. Apple has made local backup very painful recently.
Apple has done a great job at making non cloud backups suck which is completely hypocritical given their supposed privacy stance since they own the keys to the cloud backups, so they now own every iOS user’s data (except those using ADP).
I use backup over WiFi. It still requires typing the passphrase (which they have an incentive to keep to push people on iCloud).
I’m using https://imazing.com to do the backups, I don’t remember the hard requirement I had for it but I think it’s because it initiates backups on its own, so the only manual step is the passphrase prompt.
You can customize the initiation conditions like minimum battery, time period. It’s not the best software ever but works fine as a set it and forget it solution for me.
Time Machine can do encrypted backups to any SMB server and iOS can back up to a Mac (over WiFi) so you can quite easily back up all of your Apple devices without iCloud. The iOS devices periodically sync to the Mac, and the Mac does incremental backups to the SMB server. The Time Machine backups are to an encrypted disk image containing an APFS filesystem on the server, so the server just sees a sparse bundle with a load of files inside for chunks of the disk. You need to back up the encryption key separately if you do this, but it gives you off-site backups.
Or simply encrypting yourself before uploading into the cloud?
Btw. I guess we can assume that UK wants similar data access from other cloud providers. So if people store data in some other big cloud and expect it to be encrypted securely, they are quite likely wrong.
And I wonder about smaller cloud setups. I guess UK will go after the largest providers first (Apple, Google, Office365, Backblaze…); but after that they might make the same demands (i.e. “accessing stored data without the victim knowing”) from personal Nextcloud instances?
I wonder about Google’s Android backup service: it’s supposedly E2EE.
Any changes to that service in the UK lately?
E2EE doesn’t say a lot about how many ends there are. I suppose the UK gov’t (and many others) are fine if they are one of those ends as well. In a system that handles both E2EE and storage, that’s painfully simple to do.
It’s very accepted at this point that the Ends in E2EE must all be end user-controlled or it’s wire encryption and not E2EE
My reading of @pgeorgi’s comment is they’re suggesting Google have perhaps stretched the definition of “end-to-end” beyond generally accepted limits. That is, in such a way that if legally challenged Google may respond, in floral legalese, “the number of ‘ends’ were never defined”.
But maybe I’m reading too far :) It’s a plausible theory in any case, albeit conspiratorial in the absence of evidence. Conspiratorial thinking can be a fun and beneficial exercise, sufficiently constrained.
It’s basically impossible to ensure, though.
“E2EE with key escrow” would add a miniscule amount of data and complexity but provide a NOBUS interface into the data for whoever owns the escrow key:
If the software provider is the same organization as the storage provider, they can hide the matter even better: for example, increase session id length and encode the encrypted keys in those spare bits in an https header that looks pretty random to begin with. Filter out bits that represent the encrypted key on the server and pass them to the government as they come in.
From everybody’s perspective except those controlling the escrow key (that government), it still looks like a complete E2EE scheme. In particular, the storage provider can’t access the data, so that’s stronger than wire encryption.
Those encrypted keys are so small, relatively speaking, that they won’t necessarily raise red flags in transit or at rest. The only way is a complete audit of the software. Between “app stores” as preferred delivery mechanism and “auto updates” being applied whenever the distributor wants (or is asked to), at least on platforms like Apple’s/Android that sparked the discussion, you rarely can be sure that you’re running what you audited.
so by “basically impossible to ensure,” you meant specifically under the regime of mobile app stores and auto-updates.
That’s the context of the article, and it’s the reality of most computer users these days. My important data is air gapped, which sidesteps the entire issue, but that’s far from the reality of most, and so is compiling your own E2EE system software after carefully auditing it, from the firmware and kernel upwards.
I think there’s a middle ground where source code is available and builds are signed and reproducible.
You have to wonder if they’ll outlaw encryption entirely. I mean, you would expect the true criminals to simply move to some homegrown system where they encrypt things themselves. It’s only the lazy/dumb criminals they’ll catch with this Apple thing.
This severely reduces the security of passkeys. It makes email access all you need for account access, and it makes passkeys which are not phishable into something that is phishable.
That doesn’t mean it’s a bad idea. It’s probably fine for certain things. Maybe even better than passwords for most things.
https://community.ibm.com/community/user/security/blogs/shane-weeden1/2021/12/08/what-makes-fido-and-webauthn-phishing-resistent
Its not phishable because the key is tied to the domain.
In the proposed setup, the thing that is phishable is the magic link, not the passkey. The article’s suggestion downgrades the unphishable passkey into a phishable magic link.
Okay, maybe I’m missing something, but how is a magic link phishable?
The service providers email is not going to be intercepted by the fishing attacker. So the link is always going to point directly to the service provider’s page.
Are you talking about someone phishing to get into the email account?
If it was something like a one-time token, like, please enter this six-digit number, I could see how that would be phishable. But a link is not phishable on its own.
I think you’re just misunderstanding what phishing is. When a person phishes your password they get you to reveal your password to them, usually through some form of social engineering such as tricking you into thinking they are tech support or something.
A magic link is easily phished: the attacker just has to convince you to forward the email to them.
A passkey is not phishable, because an attacker can’t convince you to give it to them.
I would call that more of a tech support scam than phishing. Where do you draw the line? If they can ask you to forward a login email, they can probably ask you to install/activate TeamViewer or something similar… From there they can just ask you to login with the passkey and grab your cookie or something. Or just inject malware and grab the cookie from the chrome/firefox DB. Or, hell, even the passkey private keys themselves.
No matter where you draw the line between confidentiality (or authn/authz) vs availability / recoverability, or, failing open vs failing closed, there will always be tradeoffs. It seems fairly obviously context dependent to me. Are you a large enterprise with 24/7 IT support for your employees? Sure, lock it down to the max, 100% . Are you a “for fun” social media website? Why not make it easier to use and harder to lose access to your account… your users will thank you.
Let’s note that these emails will typically say something like ‘WARNING: do not share this link with anyone or your account will be compromised’. Sure, even after that a good scammer might get some hapless users to forward theirs. But I’d like to see some examples of that rather than ‘lol’.
More realistic phishing flow for magic links:
Now, step 4 relies on the user doing the Wrong Thing, and it is easier to do the Right Thing than the Wrong Thing here. But users are used to entering codes that were texted or emailed to them into websites or apps, and honestly, the average user doesn’t know what a URL is.
There are quite a variety of things you can do in the email to funnel users into doing the Right Thing rather than the Wrong Thing that BADSITE told them they needed to do in order to get back into the GOODSITE. But as long as the Wrong Thing is possible, there are a certain number of users that will do the Wrong Thing. Magic links are… harder to phish than passwords, I guess, if you do them right? But definitely phishable.
Theoretically, anything is possible. In practice, it’s much harder to find real-world examples of it happening than it is to make up theoretical scenarios 😉
The real world scenario is the decades of experience with phishing, passwords, and 2fa.
And yet no one can point to a single example of magic links being phished. They can just argue from authority ie ‘trust me bro’
Whatever https://www.channelnewsasia.com/singapore/instagram-scam-hack-small-business-password-reset-2999176
Yep, exact same process.
https://lobste.rs/s/pihql3/you_re_thinking_about_passkeys_wrong#c_ulgv1o
I’m surprised you’re using this as an example. The article says that Instagram sent the magic link as a text message. You are talking about security and your argument is that magic links sent via SMS are phishable? You do understand how insecure SMS is–right?
Please read my post carefully where I specifically said that the magic link should be emailed. Email offers encryption and the ability to use tags with text descriptions so that the bare link is not visible. Actually go and check Instagram’s emailed magic link, it doesn’t expose the https:// URL. Taking a screenshot of that wouldn’t expose anything to a scammer and in the case that the request was legit, it would also prove that the seller owned the account!
I’m operating on the principle that as soon as you make something foolproof, they invent a better fool.
There is no such thing as perfect security. We trade some theoretical security perfection in exchange for ordinary people actually being able to use their accounts comfortably.
Doubt. If you message it correctly you should be able to make it very obvious to users that they should never share the magic link with anyone. And, I can understand convincing a hapless user to share an emailed token. But handing over an entire magic link? I’d love to see how scammers are going to phish for that. There’s a reason why magic links are so widely used today. If they were as insecure as you are implying, that would not be the case.
lol
Disclaimer: I work at 1Password
People keep making this case, but this is only true if you cannot export/sync passkeys. There are password managers—1Password and even I think Apple’s Passwords—that will sync passkeys cross-platform. This shouldn’t be an issue in practice. And, yes, you can’t remember a passkey or easily write it down on paper but given the amount of work regular password management already is, “requiring” software to provide good UX isn’t the worst thing IMO.
1P definitely makes this experience better, but it’s certainly not the default experience for most people. There are people in my life who struggle with 2FA, especially around backing up tokens. I have a hard time imagining that I would be able to get them on board with passkeys, much less installing more software to make passkeys’ use easier.
On the contrary, passkeys require zero extra software and vastly simplify the experience for ordinary non-technical people. Now they don’t need to muck around with passwords anymore, they can just tap their finger or scan their face to log in. This is the first genuine usability improvement for online security in at least two decades.
You’re right that you don’t need any additional software, but the point of GP was that additional software solves problems with the OOTB experience.
GP’ assertion:
Is incorrect. And you can read my post to see why.
Your post outlines what is essentially a way to coordinate (“sync”) passkeys using magic links. With that, yes, you can use multiple devices to your heart’s content.
Using magic links works in theory and likely in practice, but it isn’t foolproof either. I’ve seen setups where someone hasn’t yet signed into their email on a device or their email client opens up the wrong browser/etc. There’s rough edges with every approach.
My point is simply that the ideal UX is syncing one passkey across devices using, ideally, 1st party software with a great ootb experience. This is already possible. You’re absolutely right that in lieu of that, you could also use magic links as described to work around it.
A ‘foolproof in practice’ auth method doesn’t exist. So we must haggle about what is the best tradeoff between security and UX for the vast majority of end users who are non-technical, non-power users, and will never go for the hassle of maintaining password managers.
EDIT: here’s what Passage (by 1Password) documentation says: https://docs.passage.id/complete/magic-links
No. We can let the user decide. Instead, the arrogance with which some people and services (especially big cloud providers) push their agendas is precisely one of the reasons why people (including me) are very hesitant with passkeys. History has made us aware.
As I’ve said many times, for ordinary non-technical people, this is not the kind of decision that they care about nor want to make. Normal people just want secure accounts that are not extremely difficult to use. They are not going to set up password managers. Many don’t even bother to remember passwords; they just log in every time with ‘forgot password’.
For power users like yourself, you can just use a good password manager to store all your passkeys and never have to use magic links at all.
I personally don’t find it productive to engage in discussions about ‘arrogance’ and ‘agendas’. All the options are in front of you, you have complete freedom as a user. No one is locking you into anything. Not sure what ‘history’ you are ‘aware’ of, but if it’s something relevant to this discussion please feel free to make it instead of spreading FUD.
Do I? Last time I checked GitHub forced me into 2FA, for zero increase in security since I already use a password manager, and I stored the second factor in my password manager for convenience.
Yes, but it’s zero increased security for you. For all the GitHub users who use the same password across N different sites, TOTP codes are a massive improvement to their security posture. Which, in turn, is good for everyone when you start to think about the supply-chain security risks.
It’s a 100% indisputable fact of life today that, if you have a user pick a password, some users are going to re-use passwords from other sites and/or use a very weak password. Passkeys bring the advantages of password managers to everyone else: it’s both way more secure because it’s a unique token for a single site (which is also significantly harder to phish for!), and it’s more convenient because it gets filled in for you. And, unlike, say, Chrome’s built-in password manager, it’s not something you can just ignore and do insecurely anyway.
Personally, rolling out passkeys has barely affected me at all (I’ll take a few seconds to set one up in 1Password if given the option on a site). But– hopefully– it’ll raise the bar for security for everyone else, preventing a lot of the actual practical attacks we’ve seen affect ordinary people.
It’s not black and white. Counterexample: person A uses github for their library X, person B relies on X. Now A loses access to their account and gives up. No further security updates for X unless B actively switches. Now you can claim that this is a rare scenario and I would agree.
Still, my feeling is that those pushing for passkeys are actively trying to talk down or hide the negative parts. The same for 2FA/MFA.
Furthermore, I suspect that the increased control and datamining is something those companies really like. That’s why so many companies only require a phone number. Or other data. Google employees dark patterns. When logging in, it ask you for your birthday and does not even allow you to reject just close the question. It seems like you are forced to give it to log in. However, you can actually just close the browser tab and you are already logged in.
Sorry, but these things take a away trust. At least for me, the burden is now on those services to proof that they are not having bad intentions. And right now, it looks to me like they have. Hence, I’m not willing to give them more power.
Oh, I do agree with you here. They have a point, and that’s precisely the problem.
Well there you go. GitHub requires users to set up security factors, as is their right. And you the user can store the security factors in your favourite password manager, as is your right. Each party in the transaction has all the freedoms it needs to operate.
There’s a tension between their rights, and that of their users. I was lucky they even allowed TOTP, because from their UI I could clearly tell they preferred webauthn. And if one day they decide I need to use a passkey with remote attestation, where all the approved providers only accept an app that runs on an unrooted Android or Apple phone?
Call me paranoid, but since that’s currently the best way I know of to actually secure an account for most users, they have a justification for going this route. And then you could say I am totally free to use any other service instead of GitHub… if it wasn’t for the obvious next step: policies of not pulling in code from sources other than properly secured providers, where “properly” means MFA of the kind I’ve just outlined.
Feels like the old freedom/security tradeoff all over again.
You realize that even if passkeys didn’t exist, the policymakers would still exist and find other ways to make and enforce these policies, right? What you are arguing about has nothing to do with passkeys except in the most tangential sense.
There is in the standard itself (Webauthn I believe?) support for cryptographic verification of the passkey provider (the entity/software/dongle that generated the key pair). Which means the standard supports remote attestation. While remote attestation has some legitimate uses, putting it right there in the standard facilitates abusive generalisation.
So there’s your tangent: the standard is an enabler, and I don’t like enablers.
So if I understand correctly you don’t like companies that manufacture kitchen knives? Because they are enablers of people who can do bad things with kitchen knives?
Ah, at last we’re talking trade-offs! My opinion here is that putting remote attestation in the standard does more harm than good.
Conversely, I believe allowing end-to-end encryption (the kind governments can’t wiretap ever), does more good than harm.
Quite a few things stayed accessible exactly until it became very cheap to make them inaccessible, though.
And good web security posture was inaccessible to most ordinary people until it became accessible with passkeys.
Good passkey security posture, for which availability is included, is not available to ordinary people.
Passkeys are a couple of years old at this point. Passwords are decades old. Give it a minute.
This is a lie. «Whether you can back up the passkey» will only become a simple question if the answer is «no, you are beholden to the vendor»
Irrelevant for ordinary users, and missing the point. Read my post, with my strategy backing up passkeys is an obsolete way of thinking when you just log in on any new device with a magic link.
Does this require not providing any alternative for those who do use a password manager? Like, if there’s an alternative, then some non-technical users are gonna use it and get pwned, so we’d better not?
Password managers can already save passkeys. Power users are already well covered here.
Sounds cool. One remaining snag though: can I opt out of email recovery? Chose my own availability/breach risk tradeoff?
In my design, no. It’s passkeys + magic links.
But this is just my design and recommendation. Others can obviously implement whatever they please. I just happen to think that the added complexity would not be worth it.
Oh I agree it’s far the the default experience, and I’d say far from the ideal experience. My early work on 1Password was its onboarding process and I’ve sat in on enough user interviews/user research that I’ll be the first to say there’s plenty users don’t understand.
And yet, when keepassxc tried to export passkeys:
(From https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994182200)
Frankly, I think that assertion was an overreach. He explained later that RPs (Relying Parties, ie service providers) could block KPXC because it doesn’t properly verify the user when required to:
That is a choice that RPs can legitimately make for user security reasons. But I don’t see how they can block specific passkey managers by name.
Attestation existing in the protocol at all seems dangerous to me: inevitably, someone will start whitelisting specific providers “for user security” and then users start having to spread passkeys among providers and non-big-tech providers get frozen out.
That is already happening. The Austrian governmental ID maintains a limited set of passkeys (all hardware) that can be used. If you try to enroll a different one it will be refused. https://www.oesterreich.gv.at/id-austria/haeufige-fragen/allgemeines-zu-id-austria.html#fido-compatible
You mean it will be rejected?
I suspect GP meant refused.
Sorry I meant “refused”. Fixed it.
This is not an allowlist, it’s an example of conforming hardware. The FAQ answer says:
If you follow that link it shows how most browsers already support it. So the hardware list is not really relevant.
It is an allowlist. I have a FIDO2 level 2 token that is certified and not accepted because a-trust blocks it. There is also no browser or software implementation, only specific keys are allowed.
Support “it”? The it in question is allowing me to use my own hardware, without a third party veto.
The protocol allows for third party veto by design.
It allows for third party veto in case of missing required security attestation. Security standards sometimes need to be strict. This is no different from sites disabling TLS <1.3 for security reasons.
Can you explain to me how I can configure my TLS library such that it only allows connections from Google implementations of TLS 1.3 running on Android, and blocks any implementations written by someone other than Google?
This would be equivalent to attestation – instead of requiring a correct implementation of an open protocol, attestation requires a specific device or manufacturer.
That’s incorrect. Attention just says what level of verification was done and what the authenticator was. Attention in and of itself doesn’t require anything; it’s inert data. It’s up to each Relying Party (ie service account provider) to decide what attention requirements they want to enforce.
Typical passkey implementation guides just recommend that attestation be set to
preferredorrequiredon initial registration. They don’t recommend that specific devices be allowlisted. See eg https://simplewebauthn.dev/docs/packages/server#guiding-use-of-authenticators-via-authenticatorselectionAnd if you think about it for a second, it’s obvious why. WebAuthn is a web protocol. The web is built on top of open access protocols where anyone is supposed to be able to participate. If passkey SDK providers start recommending that it be locked down to specific hardware, that will quickly break the web. And nobody wants that.
Great, if it’s not meant to be used that way, it should be no problem to remove it from the protocol.
I have no opinion either way. Maybe you should take it up with W3C!
You’re the one who cares about passkey adoption. This is the biggest blocker.
Maybe you should?
It’s just deleting sections 6.5 and 8 from https://w3c.github.io/webauthn/#sctn-defined-attestation-formats
You seem to be projecting your incentives on to me. Like I said earlier, I don’t care either way because I think this ‘problem’ is way overblown and only a theoretical concern. Relying Parties ie account providers don’t have an incentive to go out of their way to block large swathes of potential users over which devices they’re using. That’s a great way to kill business. And in practice most people are using devices which will have certified authenticators anyway.
Any way you look at it, this is a moot point.
«Security attestation» is slang for «proof of not being under end-user control» (unlike TLS version)
Close, but it’s actually ‘we reliably verified that the claimed user is the one making the request’. So actually the opposite of ‘not under end-user control’.
This is advertisement.
This is probably close to the technical definition.
Is how the accepted device list for attestations will be implemented 99% of time, and I would like to see the remaining cases.
You seem to misunderstand what attestation is. It’s got nothing to do with the user.
The only information that attestation demonstrates is who manufactured the device making the request.
Like I said previously, I don’t see how a specific passkey manager can get blocked. The attestation just says whether user verification was done or not. It doesn’t say what the password manager is (as far as I know).
“Attestation” sounds like the kind of remote attestation sometimes demanded of some specific services.
For instance, you get hired in this security company, and they mandate a second factor with a USB dongle. The dongle has 2 private keys: one for you, that could be changed or reset at any time, and one for itself, that comes with a certificate that the device had been manufactured by this or that company.
Remote attestation would be that when you plug your key, the IT system not only asks for your key, it also asks your dongle to certificate the public half, and since the dongle is configured to provide certificates only for keys that it generated itself (that’s a promise of the dongle manufacturer), your company knows for sure your private key can’t leave the dongle, and thus you’re really logging in with the dongle.
Now it makes sense for companies, because leaking employee credentials doesn’t just harm the employee, it may harm the company itself. In this case you may not want to rely on the goodwill or conscientiousness of the employee, and just mandate they use the company issued dongle. That is much less of an issue with public-facing services, where when an account is compromise, the damage tend to be confined to that account.
Now replace “dongle” by “ID provider”, point out that GitHub repository or NPM package compromise can easily have far reaching consequences, and you have your foot in the “oligopolies in the name of consumer protection” door.
This is completely wrong and not at all how passkeys work. Completely irrelevant.
The attestation says which device was used on enrollment. ID Austria as mentioned in another comment here blocks all but a handful of dongles: https://www.oesterreich.gv.at/id-austria/haeufige-fragen/allgemeines-zu-id-austria.html#fido-compatible
(You can try it yourself, there is no way to enroll 1password or a similar thing, it needs to be one of those hardware tokens. They even denylist old yubikeys by firmware version)
That’s not possible at scale. The ‘someone’ would have to go to every Relying Party and get them to accept the whitelist. The decision is up to each Relying Party ie account service provider what attestation/authenticator they will accept. So your bank might decide to accept only certain known and certified ones, while your ecommerce site might accept others.
But again, I think we are getting too bogged down in the weeds here. For the majority of ordinary, non-technical people, who will use their platforms’ built-in passkey management, all this will work completely fine.
Syncing passkeys with 1P is a good experience. A little better than syncing passwords. And I think that’s the most we’re going to get out of passkeys.
Why is it so obvious when something is at least mostly written by (or expanded/rewritten by) AI?
Just yikes.
Not a native english speaker. I use Grammarly, and yes I agree it is killing the tone. Making it look terrible.
You can check my other blogs here https://aravind.dev/layoff/
I peeked at the docs and it looks like it has customizable key bindings and themes, but I’m fairly certain I must be missing something.
What does this terminal emulator do that makes it great? Does it unlock new workflows? Is it just fast? Or is customization really that important to people? Links to explanations welcome!
I say this as someone who uses the terminal (with GNU Screen) a lot, but hasn’t experimented with new terminal emulators (because I don’t know why I should—existing performance is fine for me). For the record, I’m a “just use the defaults” kind of user.
Edit: cross-platform is actually an interesting feature I hadn’t thought about. Oh, but maybe no Windows support yet.
Edit again: this might be the info I was looking for: https://ghostty.org/docs/features
And also: https://ghostty.org/docs/about
Native tabs and splits would probably be an upgrade from my current GNU Screen workflow. Ok, maybe I’m getting it now…
https://ghostty.org/docs/about
https://gpanders.com/blog/ghostty-is-native-so-what/
You can stop reading this comment if you don’t give a shit about marketing ghostty, but that copy should maybe be more prominent, as it took me a few clicks to find it too.
Also, it still isn’t really a compelling pitch. As someone who uses iTerm and downloaded ghostty to play with it, I couldn’t name one reason for switching to it. Native tabs? I never noticed or cared that iTerm tabs weren’t native. Fast? What’s an example of how I would notice that?
Congrats on the release though! The fact that I, a terminal non-nerd, can’t tell the difference between iTerm and ghostty after the 1.0 release probably means it’s really great.
Fast is effectively how quickly can the terminal actually process the output of whatever applications are writing to it - parsing all the ANSI escapes, newlines, carriage returns, and such to properly update its internal representation of what should be visible on screen.
If this is slow, the application has to just hang out blocked on a
write()call until the terminal finishes dealing with it - a very obvious way to notice this is when youcata really large file how quickly you are able to get your prompt again. Complex TUI apps like text editors with a lot of styling going on are often noticeably more responsive in “fast” terminals, especially when doing things that redraw the whole screen like scrolling.also iTerm is native: that is, it does use Mac UI APIs for tabs, windows, text rendering, and so on. It’s just that most of the non-ghostty fast terminals (alacritty, kitty, etc.) are not - e.g. kitty just renders tabs with an additional bit of text UI, so it feels more like having tmux built in than the way iTerm or Terminal.app or Ghostty’s tabs work like other Mac apps.
Got it. So I guess iTerm is fast too? I ran
treein a huge directory and ghostty was trivially faster at completing:time tree…136740 directories, 782744 files
I ran
fd . / --color=always > ~/outuntil I had 1.3GB of fully colorized content (8,455,044 lines; every line has at least a few colour sequences but some many). Ghosttycats it in 12.1s; iTerm2 takes 38.3s.treewould have spent most of its time in filesystem calls, not waiting on writes to the terminal to completethe bit that’s nice day to day about being in a fast terminal isn’t really how much faster you can
cata big file, but more how TUI apps have less input lag, especially when doing things that affect large chunks of the screen (like scrolling in editors, or resizing panes in tmux/zellij) but to me its noticeable even in things likefzf’ (I make heavy use of fzf’s ctrl-R replacement for quickly recalling previous commands)Oh, right. Okay yeah I get it.
With
tree > /tmp/tree.txt && time cat /tmp/tree.txtI see:
Have you tried to run
time tree > /dev/nullto see how long it takes without outputting anything to the terminal? I think the vast majority of the time you see taken up is from IO operations related to listing the files on disk.You could pipe the output of
treeinto a file and then output that withcatfor a better test.Also I would kind of argue the term “native” is meaningless in the context of Linux. What even is “native” under Linux? Ghostty seems to use gtk, is Qt not native then? What about xlib?
Yes, I address this in the about page I believe. My argument for “native” is that it’ll feel like an idiomatic app and GTK is the default for most large distros that that is a reasonable thing to say (I’d also say QT is native fwiw).
If you reverse the argument it also makes a bit more sense: Ghostty will feel more “native” (with the above definition) compared to Alacritty, Kitty, etc. for most users. It’ll feel closer to Gnome Terminal or whatever your default is for your desktop environment.
GTK was a pragmatic choice.
While those are the defaults, most of them also have a KDE spin (and others).
I’m running KDE myself, and anecdotally I see more and more people switching from gnome due to some design choices. I know you don’t have to support KDE but I also think that it’s more precise to say “gnome native” then Linux native.
Feel free to contribute alternative frontends :)
Thanks. I did eventually find that first link, but most of my confusion was because I couldn’t find much info on the home page, as well as the /docs page. Once I found the menu button in the upper-right corner I was able to find the feature overview and about page—which were much more helpful in figuring out what makes Ghostty interesting.
Eh, I’m not so sure, you can
screen -d -rfrom a laptop then pull it back to your desktop… never seen a native thing do that. I switch between desktop and laptop a lot, so this kind* of thing matters to me.Good point. I also tend to disconnect and reconnect when I switch to a laptop. I might have to check out your terminal emulator :)
Although I bet there’s no technical reason we couldn’t have both native split UI and the ability to dis/reconnect.
Oh, I’m sure it’d annoy you. I fixed what bugs me and implemented what programs I use needed, but didn’t bother with much else. Odds are we overlap on a lot of desired terminal things… but probably not all things. My thing has basically no customization settings either - if I want to change something, I know where the source is! Heck, the makefile literally has hardcoded paths to things on my computer, so it isn’t even likely to build on someone else’s computer!
Yeah, I wrote a longer comment elsewhere in this thread in reply to the ghostty author with some thoughts on it and ideas for how I’d do it. I also learned (after writing that comment) that tmux supports some kind of command protocol with its parent terminal for this purpose and that’s on the ghostty todo list, so perhaps someday they’ll make it work.
Can’t remember if this was doable in screen but it’s easy in tmux:
I just tried it in xterm and tmux, and it doesn’t work there. That said, tried it in konsole now and it half works, it let me scroll up but not back down. So it is probably reliant on one of those keyboard extension features in the newer terminal emulators (that I’m pretty sure didn’t exist in 2013 when i wrote mine). Also doesn’t work with the mouse wheel at all, though i do see tmux in konsole showing bash command history with the mouse wheel which is different, so sure looks like tmux can rebind that too with probably a couple more lines of config.
In any case, good to see solutions at least becoming available in the mainstream now!
With xterm you have to override the default bindings (which are used for the built-in scrollback facility) and make them send the escape codes:
You can put this in .Xdefaults or .Xresources or pass it on the command line using -xrm:
There is probably a way to make it work with the scroll wheel too,
<Btn4Down>and<Btn5Down>or something along those lines.Wow, HN just keeps getting less and less on topic.
What stuff is in contradiction to its guidelines?
The guidelines are so open-ended it would be impossible to be off-topic, but when most of the front page looks like “WSDA, USDA announce eradication of northern giant hornet from the United States” I think it’s fair to say the site isn’t living up to its name or original intention anymore.
Which is fine, cause I think that’s what their audience wants.
HN is Facebook for STEM grads.
Thank you, I’m stealing this
Speaking to the first part: the platform is 30 years old. A very junior dev only knowing about the SPA they are working on or some other narrow slice of the platform is not a problem or a disconnect: it’s a natural consequence of building a platform layer upon layer for many decades. Just because you learned the platform when there was 1 layer and have been keeping up with each layer since doesn’t mean new developers can do that today. Give people time. Help them learn the platform from the ground up. Have patience.
When a developer has been building for the web for 10 years and then still doesn’t know how document requests work, then you should be worried.
Your point is well-taken but your example is behind the times. Web developers with 10 years experience who don’t know how HTTP works is absolutely a thing that happens now.
Sounds contrived. There are people in every industry who don’t know their foundations but can still do valuable work.
I feel like the number of layers is actually a problem, both for understanding and for performance. But that is probably just my age talking as well.
There are a lot of comments here that are nitpicking but in my experience this is totally correct. Turborepo, for example, decided to use comments in their config .json file and it’s fine. The world didn’t end. The RFC police didn’t arrest them. There were no casualties.
As one of the nit-pickers, I’ll say I also agree with that point. What is more iffy is
For the security risks mentioned elsewhere.
As far as I can tell, the security risks are around “what if someone implements this incorrectly, then two different parsers could disagree about the presence of a key”. I’m not going to remove that wording, but I will add a footnote mentioning the potential downsides that apply outside the context of config files if you do it wrong.
Thanks!
Really great post.
I was initially confused to see OT lumped in with CRDT because I didn’t realize it tried to be conflict free. I used to work on a p2p app in the 2000s that used change synchronization, in a way that is very similar to OT, but it would only resolve unambiguously correct conflicts. I thought that was OT but I guess not. TIL!
I love the conclusion “Offline editing is a UI/UX problem, not an algorithms problem”
My favorite example of this idea is git. Software developers are so used to git’s (default) theirs/yours merge UX that it’s hard to explain to them that it is IMPOSSIBLE to properly merge source code without the base. In other words: git is solid because it won’t lose data on its own, but its UX demands that you lose the data for it as an unwilling accomplice, and we’re somehow okay with that. No one says “git’s default configuration loses data” simply because it is the UX that loses the data, not the underlying algorithms.
btw https://www.moment.dev/blog doesn’t load for me in Chrome or Firefox, probably because it’s making failed requests to localhost:3333