No source code? No tech details? No reason to trust you with my browsing? For all I know, this could be MITM'ing my sessions and exfiltrating my data.
Being a paid product gives me exactly one guarantee: that I will be that much poorer. It doesn't increase my trust in the product in any way, it doesn't say anything about what the product is doing for my privacy or security.
This is a very poor marketing piece.
> Wondering why browsers are usually free?
Let's say I am. Care to answer the question rather than passive-aggressively hurting my choice of browser?
> No source code? No tech details? No reason to trust you with my browsing? For all I know, this could be MITM'ing my sessions and exfiltrating my data.
If open-source is what instills trust, then Chromium would be the most trusted browser. Instead, in practice, we should look at actual 'phoning home' habits and browser's business model to tell us what it real agenda is.
Luckily we do need source code at all to check if any browser is sending data anywhere. A simple network proxy will do and is much easier and more accurate than supposedly going through millions(?) lines of code.
In case of SigmaOS, at least the business model is more likely to not create privacy-related friction. I haven't checked it with network proxy, but somebody pointed out that crash logs are automatically sent to Microsoft which is not a good sign. Those are the things I would focus on.
I can only tell you that your session data is yours alone, and that we will never monetise our users' data.
Free browsers typically make their money from search engine royalties.
Users will only pay us if they think the value we're giving them is worth it, and that will keep us developing the product towards what users will benefit from, faster than traditional browsers.
But it appears that Apple already stole your thunder on consumer privacy, and that they will be Very Hard to catch up to; private relay is basically TOR lite for grandma, private email is email aliases that ordinary users can use, etc.
Plus no discussion on ad blocking extensions or password management?
If this is a browser that is launching on Apple’s ecosystem while charging $$, then you have to swing harder than just vaguely insinuating that other companies are sellouts on privacy.
And is there any plan to open source so that communities can actually vet anything?
> Free browsers typically make their money from search engine royalties.
Please name names and map them to that.
I know that Chrome is owned by Google. I also know that Firefox makes money from Google for having it as the default search engine. I configure my browser to use DDG. How is your product any better in terms of preserving my data?
> and that we will never monetise our users' data.
This is already telling; you're admitting that you gather user's data. Is there a clear consent form for that in place? Does your application and your company's data handling conform to GDPR rules?
But if you want to sync your data across devices, you’d have to upload your data (though we’re trying to move to iCloud for this so we don’t have to keep it).
Our privacy policy is available on our website and on the app before you login/signup, and we make sure to handle the data according to GDPR rules (though parts of GDPR are a bit lax, so I’d like to say better), considering it’s illegal not to :P
Hmm, I'm not sure how we'd go about allowing that at the moment without having to integrate each solution ourselves.
How about the sync generating a file where you want it to, and you can sync that file using your current cloud storage solution? Would that work for you?
I will. Thank you for doing a great job anyway. I don't actually feel angry or demand anything from you, although I might sound this way. I just expressed my thoughts which many people obviously share.
May I, however, ask if there is a serious reason to require Big Sur instead of supporting Catalina, Mojave and High Sierra also? I understand you probably don't want to waste resources on actually supporting them but perhaps you could just build against them and let users use it on their own risk?
We're using SwiftUI and WebKit features that were added quite recently (MacOS doesn't get nearly as much love from Apple as iOS). This keeps our product iteration cycle quite high, and the worry is having to implement cumbersome solutions if supporting previous OSs.
I'll have to look into it again to see if I can go back just a bit maybe and assess how much time it would take to support those versions.
I can speculate this can actually attract even more of the target audience to you. Mac people probably feel more enthusiastic about Mac-specific software announcements and are steadier to go and take a look at something Mac-specific than at yet another generic browser. And for the conversion rate - this probably even is a serious boost.
And those enthusiastic about Mac, also care about things like how 'macOS' is written. Attention to detail matters and shows your own level of dilligence.
At the moment, older model Raspberry Pi's and other ARM-based devices - everything else has moved on to 64 bits already. I don't think 32 bits needs to be supported anymore for consumer applications.
Try not to let the shallow dismissal get you down. While this product is not for me, as I'm not a routine Mac user, I appreciate that you went with a native app (presumably based on WebKit) rather than Electron or CEF. I do wonder what you'll do when/if you decide to do a Windows port, since WebKit on Windows isn't a popular combination.
