Talk:Brick

Difficulty of bricking an iOS device

"(unless very specifically designed to do so by a malicious person, which has not been seen "in the wild")" --- Wasn't this seen here recently with the nvram hack that was discovered here?? Given it hasn't been used in an actual tweak or a package yet... MWoolweaver (talk) 16:28, 19 February 2015 (UTC)

What I meant by this sentence is that nobody has deployed this method maliciously/intentionally in a package on any repository that I've heard of - they have all so far been clearly marked as dangerous "proof of concept" packages/instructions, not meant to trick you. In other words, it's not "in the wild" as a malicious tweak that people might randomly run into right now. I'd welcome revising this sentence with alternate phrasing that makes this more clear. Britta (talk) 05:07, 20 February 2015 (UTC)

Maybe we could advise people to delete/rename nvram binary (e.g. mv /usr/sbin/nvram /usr/sbin/nvram.disabled) so that potentially malicious tweaks can't use it (it's easy to bypass by supplying another copy of nvram with the tweak though).--Danzatt (talk) 08:19, 21 February 2015 (UTC)

Yeah, that doesn't really protect people, so it's not super useful to recommmend. In general I believe this page is mostly helpful as a technical reference for people curious about how bricking works instead of as a user guide for avoiding it. :) The user advice would mostly be "avoid installing stuff from repositories and developers you don't trust", with maybe some explanation for how to determine which repositories and developers to trust. Britta (talk) 23:12, 21 February 2015 (UTC)

Maybe a "trusted sources" page should be created somewhere, including repos that are from trusted developers that have released a certain number of tweaks on the official repos, this creates a place where users can be sure that the repo that they're adding is secure. --Haifisch (talk) 01:38, 23 February 2015 (UTC)

We could instead write something like a "human readable algorithm" for helping people determine trust/reliability on their own - the steps could be something like this:

1. When you google the name and/or nickname of the developer (or search for it on Reddit, Twitter, and so on), do you find a Twitter account and other information showing that they interact with other developers and jailbreak community members and generally have a good reputation online? That can be a good sign. It can also be a good sign if they seem to use their real name as well as a nickname, since that means they've tied their real-life reputation to their development work.
2. Is the tweak in a default repository? If it's not in a default repository, is it on the developer's own repository, as verified by their Twitter account or website or other information provided by the developer? If it's in the developer's own repository, have they released tweaks on a default repository?
3. Does the tweak make big claims about what it can do, such as hugely reducing your battery use, saving you tons of disk space, or something else that sounds very difficult to do on a technical level? You should research a tweak more thoroughly if it makes big or complex-sounding claims.
4. ...and so on.

Britta (talk) 01:48, 23 February 2015 (UTC)