Would be more interesting if the link was encrypted client-side using the provided key. That wouldn't change the UX much and it means you can guarantee that the shared URL will remain private.
But anyway I'd expect if someone is naive enough to use this website they would also share the URL and password using a single channel, which would be the same as not "hiding" the URL at all.
I can't find the reference now, but I think I read somewhere it only redirects when the user got there by clicking on an ad. In that case it would make a bit more sense - the script essentially swaps the intended ad target to that sport gambling website. Could work if the original target was a gaming or sport link.
One example is the calendar that keeps getting worse release after release, so much that I had to switch to macOS calendar.
Global Inbox also got broken several years ago and never fixed, since it seems all their energy goes into making things prettier at the expense of making things work.
And even that is a matter of taste. They tend to make things resemble some combination of an Android app aesthetic and a Google Chrome aesthetic. For example, replacing dialogs with item hierarchy trees with a scrollable flat web-form-like preferences page.
At least they backed out of the switch to monochrome folder icons. 8-\
I don't know if that's his use case, but we had many users tell us they share their account with other users so they want the data to be encrypted even when logged in.
Of course if they share their computer, someone could install a keylogger and wait for them to type their passwords, but I guess that's an extra layer of security that may help a bit.
If AWS and other cloud providers gave if only 0.1% of the profit they generate out of these open source projects back to the developers we probably wouldn't have this problem. Unfortunately they don't and it's only fair that eventually those developers take it in their own hands. It's not a great situation but it's certainly understandable.
> Unfortunately they don't and it's only fair that eventually those developers take it in their own hands.
"Fair" is somewhat loaded. The developers certainly have a right to change their product and charge for it, but it's not nearly as cut and dry in my opinion. How many contributions were made because of the completely open nature of the product? Is it "fair" to those people that the controllers of the project want to change how it's offered at a later date? Some people are happy to feel like something they have contributed is in use by a lot of people regardless of whether someone else is making money from it.
There are often lots of entangled assumptions in open projects like these. Ultimately, people have a right to offer their work as they want, so I see no problem with projects trying to request additional restrictions on how their work is used, but I also don't see a problem with companies using open projects as offerings. It was offered for free, and it's not like the cost of the offering isn't usually just the cost of the underlying resources plus some additional amount for ease of management.
Disregarding the question of if the CSP compete fairly with providers of open source SaaS, your math is broken:
AWS revenue is about $90.76B, though most of it isn't from Redis, I'd assume. But let's be generous, and assume 10% of that is. So about $10mm. For the recent version, Redis-the-company contributions to Redis-the-software were less than third of the code base, so let's say they get $4mm. That's very little revenue for a company that has a valuation of over $2B.
Revenue is irrelevant, profit is what matters. The vast majority of the cost of any redis service offered is going to be the cost of the underlying compute and disk resources used. In some cases the margins could be close to nonexistent after paying for the resources utilized and the people to manage it, and it's used as a table stakes service that needs to exist for people to want to use your platform.
The vast majority of these projects didn't seem to have a problem with large companies like Netflix using their software, even if it was put on a cloud server, as long as it was managed by Netflix. Now that the management portion is moved to the cloud provider, along with some amount of possible profit, it's a large problem? Was it not a large problem when the companies were using these projects directly? Was there not some assumption and hope these companies would use these projects by the people contributing to them?
You must mean something other than 10%, that would be $9 billion by your numbers. 0.1% would be about $9 million so would be closer to your envelope math.
OP suggested the CSP should give 0.1% of their revenue to open source software they make their revenue from. As Redis isn't the only SaaS AWS offers, I was gracious and allocated 10% of those 0.1% to it.
Got it. It would actually be less than that since the number you selected was for revenue, not profit which is what OP asked for. Looking at some prior years it looks like AWS profit is close to 1/4 their revenue, so $90 billion would leave them with (generously) $25 billion profit. 0.1% of that would be $25 million and 10% of that (your estimate of Redis's share) would be $2.5 million.
Getting a chargeback in Stripe is costly. As soon as a dispute is started there's a fixed $25 that won't be refunded even if you win the dispute.
So for a service at $4 a month which is likely to get a lot of fraudulent payments I wonder if it's really viable.
One thing he should do is immediately cancel accounts and refund subscriptions when there's an early fraud warning. They are usually accurate and help avoiding those fees.
This was my thought as well. I wonder if the author couldn’t achieve similar friction without charging. Require a card for signup but only authorize it in the case of “free tier” users. PayPal will let me do that for free, not sure about Stripe.
> "Certain data" about hand, body, and eye tracking
> Fitness-related information
> "Information about your physical environment and its dimensions"
> "Voice interactions"
That kind of data can 100% be matched back to a Facebook profile. There should be a legal definition of "anonymous data" so that companies like Facebook cannot have the opportunity to pretend they care about their user's privacy.
Considering that the legal definitions of "PII" exclude quite a lot of actual PII, I don't have any faith that a legal definition of "anonymous data" would be any more accurate.
Probably goes without saying, but Quest users are obliged to have a Facebook account. So that can't even be qualified with "if they have a Facebook account", the vast majority of users do.
As far as I know, the original workaround of using a developer registered account now requires an invite and it's hard to see that not quietly being dropped at some point and all users requiring a "real" account.
It's a shame looking in from the outside at how good the pricepoint is for the hardware, but can't bring myself to get involved with Meta. Just about the only aspect of a user (they aren't even 'just a user' if they've spent hundreds on Quest and apps, they're a fully blown customer) they aren't collecting data on is their DNA.
From ~late 2022 onwards, Quest users were no longer obliged to have a Facebook account, but rather a (non social-media) 'Meta account'.
Not defending them. Merely anecdoting that, as one of that small minority who never cultivated a Facebook account, getting and using a Quest unit had no special or far-reaching implications for me or my private information.
Recital 26 of the GDPR has a quite good definition
>To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable.
Which of course relies on threat modelling as technology doesn’t stand still. However it’s quite clear that if you can link the data in any way to an individual, it’s not anonymous.
I work in privacy and I’d even argue that collecting anonymous data is likely not possible unless using something like differential privacy. It’s more likely they are collecting personal data (because even your IP would link this data to you) and then anonymise it afterwards (i.e. store it without your IP address).
> I’d even argue that collecting anonymous data is likely not possible unless using something like differential privacy.
I think this is undeniably true.
Aside from differential privacy (which is pretty weak sauce itself), the only way there can be "anonymous data" about people is if that data is aggregated and only the aggregation is kept. The collected raw data must be deleted.
The problem with that is that there's no way to know if a company is actually doing that. All we have to go by is what they say, and I think a strong argument can be made that we shouldn't believe what companies say just because they say it. Especially if those companies are the likes of Facebook.
So, as things currently stand, "anonymous data collection" is a misnomer and any time I see a company asserting they're doing such a thing, I think that company is lying. Or, maybe worse, deluding themselves.
I agree with the sentiment (as a Firefox user who does not like the Chrome monopoly), but keep in mind this looks like a project purely for fun. The author owes us nothing and is nice enough to share their experiments. They may not have even noticed it only works on Chrome. We can certainly find a nice way to suggest them to specify that this is Chrome-only, maybe by sending a PR on the README file.
There's no need to be negative. You can even convey your message nicely.
Usually, people are receptive to feedback if the feedback is respectful and gentle.
I don't really see how this is being negative? Pedantic maybe, but negative? Do you expect everyone to tiptoe around and gloss over their feedback with layers of happiness?
Last year's releases (2023) were lagging behind.⏎
Only this yr's releases (2024) are in a timely fashion so far.⏎
However, being forewarned is being forearmed! ⏎
Both (Chromium/Thorium) browsers upstream releases are maintained by Google & both browsers contain various forms of spyware and/or telemetry! ⏎
MOAR:-
thorium.rocks ⏎
github.com/Alex313031/Thorium/releases ⏎
On a personal basis I prefer Firefox & Pals over Chromium & FRIENDS!!! ⏎
The last time I was used by Chromium was 7 years ago!!! ⏎
Carpe Deim!
no. am I wrong in thinking that the Chrome source code is not available? Chrome is built on top of Chromium. Chrome != Chromium. So how do you know what the difference between these products are if you can't see it?
Not really, there's a lot of "perhaps" and "maybe" in those sentences unlike in the title. And indeed there's no reason to think dark UX patterns do not work in the long run - Google, Microsoft, Facebook and many more have been doing that for decades and there's still around and striving.
> The better UI would be for the circles to be visually connected somehow to illustrate that only one selection is possible like you have in physical switches with more than two positions
Nope, this group tells you nothing about the fact that these are mutually exclusive, you could just as well group checkboxes because they are all related to some "Icon"
But anyway I'd expect if someone is naive enough to use this website they would also share the URL and password using a single channel, which would be the same as not "hiding" the URL at all.