The secret is still stored in the browser's history DB in this case, which may be unencrypted (I believe it is for Chrome on Windows last I checked). The cookie DB on the other hand I think is always encrypted using the OS's TPM so it's harder for malicious programs to crack
The article says "Misconfigured scanners". Many, many enterprise communication tools have such a scanner, and if your IT team is using the free plan of whatever url scan tool they signed up for, it's a good bet that these links may end up being public.
yeah I don't think OP is talking about byte perfect determinism, they just want CI not to explode. that's the triage goal, byte perfect determinism is not your first priority when stopping the bleeding on a legacy c++ project
I don't think that's the case. The games are copyrighted. The keys only need to constitute an effective anti-circumvention scheme (any technological measure that “effectively controls access” to a work) to be illegal to code for.
Yeah, sorry, when I said "entire database" I was handwaving over "the entire database of posts relevant to them". The Merkle tree structure is the root of the scaling issues which is why I think it's fair to describe it as "bitcoin-like" and it serves as an intuition pump for people to understand why it was so difficult to use on mobile, regardless of whether it was actually quite as bad as Bitcoin or not.
Eh, a lot of startups even in the 100-200 employee range are still manually inviting Slack members. It's not really the end of the world as long as you're on top of things and have good communication between HR, IT, etc. Spreadsheets solve a lot of problems (in this case, having a good template offboarding/onboarding spreadsheet in Google drive that everyone can collaborate on to make sure stuff gets done quickly).
Scuttlebutt had the Bitcoin like problem of requiring everybody to have a local copy of the entire database, with a confusing / glitchy "syncing" process to download the latest posts. I tried to use it for a few days on my Android, but it never showed any new posts and the syncing process took like 30 seconds every time I opened the app.
The page you linked even says "While this doesn't protect you from a malicious developer". The whole point of e2ee is that it needs to be able to protect you from a malicious developer. Native apps do this by having local, auditable code. Web apps don't.
That said, this project could be extended with something like a public certificate transparency log showing which versions of the code have been signed and making the code associated with each signed version available for third-party inspection, which would help plug this loophole. I haven't seen any proposals for how to do that with web standards yet, but I expect that some people have thought of a few of them. While it would be very different from the web we have today (no dynamic server-side templates, only APIs!), I think it would be a welcome innovation for web security
Correct. I do not think applications with such a vulnerability should ever be used or marketed as "end-to-end encrypted", since that implies a promise that a malicious or suborned vendor could not be compromise your communications—which, in the case of remotely loaded code, is misleading. I think this is table stakes for any e2ee communication app (e.g. Signal can do this easily since Apple and Google and many third-parties audit their code) but if it conflicts with your current app design, you should be realistic about whether a true e2ee-required threat model can be accommodated by your app.
Correct. I know that there's a lot of concerns about Mv3 and I don't want to downplay them, but from a security perspective the team absolutely made the right and necessary calls that are required to prevent the (currently widespread) abuse of browser extensions for tracking and ads injection, not to mention malware distribution.
I would trust an audited, Chrome-or-Firefox-store distributed browser extension to implement end-to-end encryption. I don't think that extends to UI elements injected into the page itself though—the UI elements where you're typing your messages have to be separate from the rest of the page to prevent malicious web apps from overwriting them and capturing your input before sending it on to the extension themselves.
Desktop applications are uniquely auditable by security professionals in a way that web sites inherently aren't. It's very, very hard to hide "send this unencrypted message to evilserver.com" in a desktop app in the same way it's possible to in a web app (because the web app could serve the evilserver.com code only to the targeted subject under surveillance and send only good code to the rest of the world). And mobile apps have the explicit review pipeline you mention. So web apps need some sort of "frozen, trustable, third-party reviewed" version to be able to match the security of desktop apps.
> I would guess this is the same for most countries except the US, which makes that statement untrue
Only if there are more organizations using ccTLDs outside of the US than organizations using generic domains within it.
https://domainnamestat.com/statistics/tldtype/all indicates that strictly based on domain registration counts, ccTLDs are around 39% of total domain registrations. So not nothing, but also not a majority.
Maybe Sable saw Cloudflare as a juicier target, since the other companies listed are all hardware manufactures and don't operate a large consumer business like Cloudflare (leading to very, very different usage numbers). Or maybe Cloudflare thought that they had a better chance at trial against hardware patents, since they don't make router hardware themselves.
My understanding is that bluesky will only support interoperating with their own centralized PLC system (which other developers currently can't access) or the did:web: protocol. Is that not true?
Yeah, I don't think moderation is "solved" at all on the community scale, but my point is that ActivityPub servers are just way more likely to be at that "community" scale, and Bluesky—as a more flat protocol with a lot of discovery and indexing features—is not. So I think they have a lot better chance of having communities that can reach a local moderation equilibrium.
This is an interesting take! I don't necessarily disagree with it—we could definitely make the DNS system more accessible than it is today—but I don't think it's the panacea either, there are still a lot of costs and paperwork involved with owning a domain name that aren't related to the actual technical knowledge required. How is my 12 year old cousin whose parents don't understand technology supposed to buy a domain name just to be able to comment on a youtube video?
My understanding is that this only works if you're using their centralized PLC DID, which I think only works if you sign up through their website? Maybe I'm mistaken about that or they removed that restriction, I don't see any mentions of that in the docs today. Users using the `web:` DID need to use the .well-known resolution system predicated on owning a domain name and their identity is tied to that domain name.
In general, I guess I'm just pessimistic of the ability for any DID system to exist that isn't either centralized or majorly user-unfriendly. I think that reasoning on a "local scope" like ActivityPub does and worrying less about global identity is just a better long-term solution for users and works better with how people are practically using social media today (think about the proliferation of a million discord servers each with effectively their own user identity....)
The other issue is that I fundamentally don't think the problems of moderation and hosting are "separable" as the paper claims—the moderation of your content is intrinsic to the question of "who wants to be responsible for hosting and paying for this content?". And people are going to want to use moderation systems that make moderation decisions they agree with and support—they're not going to want to be paying for a hosting provider that hosts content they disagree with. That's why I see the fediverse "plurality of networks" federated model winning out in the end, because it can be funded and operated by small groups of people interoperating with each other rather then requiring large centralized directory resources that nobody wants to pay for.
Except for the fact that it requires a centralized directory server that you can be banned from at any time, with no recourse. And for users, being independent from Bluesky requires owning a DNS name and paying for it yearly—a big step backwards from Mastodon where a group of users can come together and live on a server run by an admin they trust without needing their own DNS names. It replaces social trust that's more accessible for a lot of non-technical users with a more complicated kind of technical trust that requires a high level of technical sophistication (Can you imagine hundreds of thousands of twitter users all signing up for a registrar and buying their own domain names?)
I think what it comes down to is that most of the other ways to automate ID creation at scale were probably really easy to detect using ... well, probably neural networks. Because ID verification services had access to millions of "real" ID photos, I'd think a lot of fake images created using traditional automation would be pretty easy to detect (For example, having the same backgrounds/wood grain pattern reused for multiple images). So what neural network generation is adding here is basically being able to add much much more "plausible randomness" to the image (lens artifacts, dust motes, wood grain, plastic reflection, etc) in a way that makes distinguishing generated from non-generated images statistically very difficult.
This is really sad, it's a huge loss for pages that may have been taken down or accidentally deleted. I can probably count a double-digit number of startups or passion project websites that were saved from catastrophic data loss by scraping Google's cached page results, it's a real shame that they've taken this away
In the context of the full article (https://en.wikipedia.org/wiki/Iridium_satellite_constellatio...), it's clear they're talking about the polar orbits used by the Iridium constellation, which have "seams" around the Atlantic and the Pacific as the "first" set of satellites passing north-to-south overlap with the "last" set of satellites coming back south-to-north on the other side of their orbits. So of the 6 orbital planes used by the Iridium satellites, each plane covers 1/12th of the globe for each "half" of its over-the-poles orbit. So there are two "seams" where handoff is not supported, one off the eastern seaboard and one roughly over Japan.
It really doesn't. The use of the word "blow out" might be a little sensationalist but nobody would expect it to mean destroying physical equipment, especially when that equipment is in a botnet (i.e. hacked devices that are presumably legitimately owned by someone)
Ah, yeah, I was just going off a simple Google. Probably ended up on the wrong BLS page. I agree it does seem low, a search for "Software Developer" turns up on this BLS page with much higher stats—1.5M developers.
Not everything is a perfectly elastic market. In fact, nothing is. For example, if I wanted to go out and hire 250,000 US-based computer programmers tomorrow, I would not be able to even if I wanted to pay them a million dollars each, since there are only 132,740 computer programmers across the entire US. So that would constitute a shortage of computer programmers. It would take many years to create the number of educational institutions, training programs, etc necessary to have that many programmers available to hire. The same could be said for many industries on a much smaller scale—how many people are willing to relocate to driving trucks in northern Canada? Probably not as many as you'd like, even if you had an unlimited budget. How many qualified airplane pilots are there in the world? Too few—we don't have enough training programs for them and mandatory "aging out" requirements have removed a lot of the pilots we already had. A lot of new training and education programs for pilots have been started in the past year, but they're going to take 4-5 years until the supply has increased enough that we're no longer in a shortage. (And although this is a heavy topic of debate between union leaders who say that there's no shortage and airlines who say that there is, I think the amount of investment in slow and costly supply increase programs is a good sign that there's at least some amount of supply constraint/bottleneck affecting the industry. It's hard for there not to be when safety and training requirements make the supply pool so slow to respond to changes in demand).