-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Cromite Default Settings #1237
Comments
(reserved) |
thank you for accepting the invitation. defaults are to be shared and it seemed to me that you also have experience with other browsers, which I do not. these are my thoughts, is all in my opinion, and my opinion is not necessarily better than yours:
About the other points you made in your repo:
|
I generally agree with this, but I think my only concern is regarding clearing
Unless I'm misunderstanding, isn't that what the 'Always use secure connections' feature does? To quote the description: 'Use HTTPS whenever possible and get warned before loading sites that don't support it'
I agree, I think that's more desirable, which is what I thought enabling that feature by default would accomplish, but again, I could just be misunderstanding it.
I agree with this as well. I myself maintain a few comprehensive blocklists here that may be of interest for this, but regardless, I think it'd also be worth including some of HaGeZi's lists as well, they're of very high quality. I could go more into detail on this and give some other suggestions for what specific lists to use as well.
I guess my concern with this is from a tracking perspective, to quote the description: `Sites you visit can embed content from other sites, for example images, ads, and text. These other sites can ask for permission to use info they've saved about you as you browse the site'. This just sounds plain creepy to me, especially the parts about using it for ads & "using info they've saved about you as you browse the site". I'm not aware of any legitimate functionality using this feature at the moment, and seeing as how other browsers like Brave just fully remove it, and haven't seemed to have any issues, I still think it might be worth just blocking this.
Fair point, I didn't realize that it was causing DoS attacks. I'll remove this from my repo in that case. I agree, you should probably just delete the patch.
I agree, I think the way Cromite handles this right now is perfect. As an aside, I'd love to see Brave Search added as an option as well.
I think my concern was that it states it
Fair point. I usually just disable it myself to prevent annoyances and I haven't encountered any issues with it, but I think you're right, this will probably need more testing & it might be best to just leave this as it is for now.
💯
100%, I think this does help. We can't defeat advanced fingerprinting (Only Tor Browser & Mullvad Browser can), but I feel like naive fingerprinters (which most are) would take the bait on this.
This is actually a fair point. I guess I was just thinking to turn it off because I use the GrapheneOS PDF Viewer, but clearly not everyone will use a private & secure PDF Viewer like that, so it might be best to just keep in the browser by default to deter the use of any sketchy PDF viewers. I think I'll add a note on this in my repo.
I haven't noticed any issues with it myself. I imagine it'd break the 1 or 2 sites out there still exclusively using HTTP, but I think that'd be in the minority and users impacted by it could just toggle the flag for their specific use case, so I think I also agree with setting this by default.
Eh, you're right. I'm not sure why I even disabled this, it's harmless & actually useful. Going to remove from my repo. |
Clean-up (Re: uazo/cromite#1237)
httpS by default -> This will most probably be annoying for those that from time to time run a http server that can't be made secure (localhost?) or regularly visit pages that don't necessarily have to have and don't use a secure connection. Personally this will be yet another thing that I have to change if it gets enabled by default.
Making a Dark Theme setting/flag unmodifiable ? -> That's a bad idea, IDK which one you mean exactly, but I hate things being unnecessarily locked-out or restricted, I use a dark theme (non-image elements) and on whatever else possible, but regarding a browser and sites - there are some pages that have problems with non-native dark mode enforced/applied by the browser, so I have exceptions and sometimes have to turn it off temporarily to see a content properly or at all (not a problem on my side), also it tells a lot that this has been a flag for years, but Google still haven't exposed/enabled it by default to show up in the theme settings, which confirms that there's more work that has to be done with it, it's not fully ready and unproblematic.
Unfortunately enabling JIT by default wasn't proposed here, but it should've, because it's more important to load and be able to use a page at all, than be concerned so/that much about "privacy" for majority of users and I'm not even counting the performance impact when is off by default (like currently, I keep it enabled obv.), that's why there are often new issue tickets being created (maybe even discussion topics) regarding it. |
you are right and you gave me the right motivation to develop it.
no, the flag enables https-first mode. you are right though, the description is misleading (Unfortunately, I am a technician and cromite documentation is bad).
It basically does not tell the user but tries to do the upgrade automatically.
I hadn't seen that, and I like your readme. And yes, I am interested.
Yes, I'm very interested, let's break it into another issue.
again, you are right. i will look for another more appropriate description.
brave removed it completely? didn't know that, I will look in his code for why.
I would not want to insert any new engine, theoretically for the user to add it in cromite is very simple.
feature is: do not open any pages at startup (so that you have a clean browser) but allow the user to quickly return to the last page they had open. How would you write this?
Yeah, it's the number 1 issue of cromite, no test. users do it...
Could you elaborate on this sentence? |
From what I remember, localhost is exempt.
in that case it is a website issue, not a browser problem.
downloaders are not "driven" by javascript and in any case that setting does not change the behavior of the internal chromium downloader.
from the point of view of privacy is a very good idea.
you are right, for example the weather sites would definitely not work. however, then the user can edit it as they like.
no I'm sorry: it is true that they are choices, but they must be made with a certain purpose, that is, in line with the goals of cromite.
the problem, from my point of view, is not jit, but webassembly, and not so much the language itself, which is extremely better than javascript since it does not support goto and therefore extremely more secure, but the support for SharedArrayBuffer. |
Is it still a local host when I run a simple web server on my phone, make it also public (accessible by my public IP) and load it on another device not necessary on my local network ?
For which Dark Theme option/flag we are specifically and exactly talking about here (it's unclear - there are 2, one of them is to expose the checkbox in the themes setting, the other is for the preferred mode) ?, please elaborate/specify.
I thought Jit is another word for WebAssembly and that it's the same thing... |
then, with regard to this point, for now I have not looked at the code but at the behaviour:
With these results, I don't think I will look at what brave did ;) |
re: @uazo
I'd be happy to help improve it, just let me know what I can do. :)
This is an interesting and fair point - I guess the guarantees I can make are the same as any other list maintainers, or really any developers as well. I guess it'd be the same as you guaranteeing not to push out any malicious updates to Cromite (Not to say you would, I personally trust you and your work, otherwise I wouldn't be here, but I guess its a similar principle). That being said, if you have any ideas how I could add a guarantee of good intentions, please let me know, I'm 100% open to hearing and implementing them, I'd love to improve the safety of my lists. I develop them completely in the open and as transparently as possible, with the only goal to help users improve privacy & security (just like my other work). The domains added are also carefully considered & taken from my own research, so I don't just rely on or blindly import other sources like a lot of other lists do, which could also add more confidence from a security perspective. I think the ideal solution here would be reducing as much as trust as possible in the first place given to lists, so like you said, maybe its best to just disable dangerous rules like that, or at least give caution over them.
👍
Yeah, I can understand. I wonder if it'd be worth considering making a testing branch of Cromite for things like this? For instance, I know ex. Firefox & Brave have "nightly" builds where they test changes that could cause issues before putting them in the stable/main releases, so that interested users can test them first & leave feedback on any potential issues, but without having to roll out the changes for the masses. I'm not sure how much extra maintenance that'd be though.
Tor Browser & Mullvad Browser are the only browsers I'm aware of that can actually "blend in with the crowd" so to speak, they basically have an identical fingerprint across all users. I think only might've been a poor word choice, because technically other browsers could as well, but right now they're the only 2 that have actually been able to pull it off. This approach can defeat more sophisticated/"advanced" fingerprinting, but it comes at the cost of usability and UX. I don't really think this is an issue for Cromite, because:
Therefore, for the vast majority of threat models & use cases, I think we're covered. I might not be doing this justice either, so I'd recommend taking a look at Arkenfox's Wiki entry on this as well, it explains this very well. |
re: @drogga
Not necessarily, but to me that seems like an edge case. I doubt the majority of users are going to use web servers like this, and if they do, then they could just disable the setting or just hit 'Continue' on the warning. I can sympathize with your concerns here though, as I've ran servers myself, but we have to remember the vast majority of people aren't like us, and I don't think we should reduce everyone's privacy & security for that.
Sounds like poor web design and something they should fix, you should probably inform them about this.
No, JIT and WASM are different. I think JIT should definitely always be disabled by default, due to the security concerns associated with it. JIT also doesn't cause breakage, it can just make websites slower (Though this has been heavily improved and in most cases, there isn't even a noticeable difference IMO). Like @uazo said, WASM is the real issue here, since WASM does cause breakage in some cases. I think the best move would be to separate the JIT toggle from the WASM toggle, so that you could ex. still have the security benefits of no JIT, but without the breakage of no WASM if desired. (I generally disable both myself though since WASM also has its own security concerns, but I understand this might not be desirable for all users). |
ah, you catch me unprepared. but if you are really interested I will make a list.
I will tell you about it in #1245
for now I am trying to prepare automated tests, but I thought it would be easier :)
well, if that is true, I will start studying the firefox code! |
I'm serious, would be glad to help however I can. :)
This might be of interest. |
…i with the aim of making it clearer (#1237)
Personally, I disagree with DuckDuckGo. DuckDuckGo filters search results based on your IP address. beave search doesn't do that 👍 |
…1237) activated (without my knowledge!) by chromium in incognito mode for several releases, I also activate it for normal mode.
A Setting from Brave I think, did come in my Mind. Like when you close all Tabs, that your Browser closes too. I think this is a nice Feature, which I miss! Maybe that could be implemented? And thank you for your great work! And I wanted to say that I'm so thankful that you published the App on Github, instead of F-Droid. I appreciate that much! |
Just following up from celenityy/better-cromite#1, I'd like to give my thoughts & considerations for Cromite's default settings. Still super cool to hear from you, and thanks for your great work on this project.
So I guess first, under
Privacy & Security
->Delete browsing data
, I think it'd make sense to enable clearingcached images and files at start-up
by default. This would serve as a nice privacy boost, and other hardened browsers like Mull also enable this (Firefox's equivalent pref) by default.From there, also under
Privacy & Security
, I think it'd make sense to enableAlways use secure connections
by default. Very few websites use HTTP nowadays, and if they do, it's just a simple prompt to continue. This would notably improve security. For reference, Mull also enables this (Firefox's equivalentHTTPS-Only Mode
), and I don't think they've had any issues or complaints over it.Now, to
Adblock Plus
:I think
EasyPrivacy
should definitely be enabled by default, in addition toEasyList
(which we already enable by default). EasyPrivacy is an excellent high quality list focused on blocking tracking & unwanted data collection to enhance user privacy, something that definitely aligns with Cromite's goals. It's enabled in various other content blockers by default for reference, such as uBlock Origin, Brave's Shields, & Vanadium. It's known to not cause breakage or any issues.For
Site settings
:I think we should consider blocking
Embedded content
&Your device use
by default. This functionality is not only blocked by default, but completely removed from other privacy-based Chromium browsers like Brave (as well as not included in browsers with other engines like Firefox & Safari). These "features" are both very concerning from a privacy perspective, and I've yet to see them provide any legitimate functionality.I think we should also set
Protected content
toAsk first
by default. DRM/Protected content poses privacy & security concerns, and this would at least help to alleviate some of that risk, so that users can make the conscious decision to enable it for websites that need it. This is also how Vanadium & Mulch handle it.Now, for flags:
I don't see why we shouldn't set
#max-connections-per-host
to15
by default. This improves performance & speed of webpages, and I'm not aware of any downsides to it. (FWIW, I think it also might be worth moving this flag & some of the other flags inherited from Bromite to theCromite
section, rather than just leaving them jumbled in with the other Chromiumavailable
flags).I'm also curious why we don't enable
#viewport-protection
by default, does this cause any issues? This could also be nice to help prevent fingerprinting.As an aside, it looks like search is broken for Cromite-specific flags, but it appears to work fine for the
Available
section, not sure if you're aware of this or not.These are the main points I can think of for now, but I look forward to discussing this with your further @uazo, thanks again for your excellent work with this browser, I look forward to seeing how it develops in the future.
The text was updated successfully, but these errors were encountered: