The iPhone Wiki:Community portal/2017

	This is an Archive Page This page is meant for archiving purposes only, do not modify the contents of this page! To see the list of archive pages, go to the main page for this archive. If you have a reply for one of these discussion topics, move it back to the main discussion page and edit it there.
	Other Archives • 2010 • 2011 • 2012 • 2013 • 2014 • 2015 • 2016 • 2017 •

The iPhone Wiki's SSL

As a security researcher, I have a bad habit of inspecting every SSL certificate I get in my hands, I couldn't ignore the fact that the SSL Certificate used on The iPhone Wiki is provided by CloudFlare (?). If it is, then you guys better buy (with help from some donations maybe?) a Comodo Positive Certificate. Those free certs provided by Cloudflare are shared, and I heard numerous stories about it being simply circumvented or replaced by man in the middle attacks as these certificates only protect a node kinda giving user the false security illusion, but the origin server remains unprotected unless you apply for the Full SSL feature of Cloudflare that requires you to also buy a certificate for the host (if applies).

As you can see, on the FREE certificates, the origin is still not encrypted thus rendering breaches in the system.

This is how Flexible SSL works: [1]

This article worth reading: [2] GeoSn0w (talk) 19:11, 4 August 2016 (UTC)

You seem to have a misconception about what CloudFlare offers on their plans.

* All "levels of SSL" (Off, Flexible, Full, Strict) are available on all plans.

* What is only available to Business and Enterprise plans however, is the option to use your own certificate. Free and Pro plans have no choice.

That said, it should be easy enough to get a free valid SSL cert from Let's Encrypt to use between your server and CF so that you can switch to Strict SSL - even on a free plan.

Also, I'm not sure if Saurik has reacted to this already, but I'm neither seeing a CF-issued SSL cert being used on the wiki, nor does theiphonewiki.com resolve to a Cloudflare IP.

I'm seeing a RapidSSL SHA256 cert that looks like it has been issued on the 3. September 2015, and contains only "theiphonewiki.com" and "www.theiphonewiki.com" as common/alternative name.

— Siguza (talk) 23:10, 4 August 2016 (UTC)

Strange, I am seeing a CF signed cert for "graham.ns.cloudflare.com". And is also verified and issued by "Avast! WebShield" (this is kinda misleading because it is generated by my Antivirus), but the CF has no sense to show up in my firefox if you say you use RapidSSL. Actually, I know what CF do and how their shared SSL work, as I use CF myself, and trust me, you can't compare your own cert with the one they provide. Shared certs are not actually yours, they will still point to CF... GeoSn0w (talk)

It sounds like that's your antivirus/security software intercepting your HTTPS traffic. This is generally done with products that contain parental controls to block certain websites from children, but is frowned upon for privacy/security reasons. (For the record, I see the same thing Siguza sees.) --Dialexio (talk) 06:29, 8 August 2016 (UTC)

Actually, I uninstalled the AV just to test, and it still shows the same cert even after browser cleanup.GeoSn0w (talk)

To what IP does theiphonewiki.com resolve for you? For the record, I get 54.147.18.44. If someone out there has another valid cert for theiphonewiki.com, then that is quite a problem. — Siguza (talk) 13:16, 18 August 2016 (UTC)

Can confirm the IP address is 54.147.18.44 and I also see the same RapidSSL SHA256 CA - G3 cert being used. MWoolweaver (talk) 23:18, 24 April 2017 (UTC)

Amendments to Rule 3.7

I would like to propose some amendments to Section 3.7, "Do not make numerous, consecutive edits." Recently, device renames and page cleanup have been taking place. As of now, I would classify page moves/deletions as edits. In addition to the 50 edits, I wanted to know— how would you feel about adding an additional 10 actions for page deletions? Considering page deletions are an admin-exclusive action, I don't want this amendment to be misconstrued as admin abuse of power. (Yes, us admins are meant to be subject to this rule as well.)

Another amendment I would like to make involves vandalism. Although it hasn't happened on here for quite a while, vandalism can occur on the wiki. As things currently stand, reverting vandalism would technically count as an edit. I don't think that should be the case, so I would like to add some language that does not count reverting vandalism against the edit limits. --Dialexio (talk) 20:03, 22 March 2017 (UTC)

I was actually planning on making a topic on this after we had finished with the device names cleanup.

I propose the removal of the rule entirely. This rule is stupid. I have not found any other wiki anywhere that imposes limits on the number of times a person can edit in a day or hour. It's absurd. Wikis are about collaborative editing. There should not be edit limits.

Whilst I understand that making lots of edits can clog up RecentChanges, this is not a problem when you can change RecentChanges to show the last 2000 edits in the past 90 days. I could make 500 edits in the space of an hour, and this will not be a problem since RecentChanges can show a rather large amount of edits.

The wiki is not incredibly active; it's the same few people editing. Vandalism is ridiculously unlikely, since everyone has to create an account to edit and that's a silly reason to prevent the number of edits a person can make. The majority of edits these days equate to Firmware and OTA Updates and details on Jailbreak page. These edits often take up more than 20 edits in an hour due to the growing number of devices. The edits to the device names that we are currently doing involve hundreds of edits. To have to watch how many edits we are making and to only be able to do a certain number is just silly. — Spydar007 (Talk) 20:42, 22 March 2017 (UTC)

The rule was put into place is because the wiki has seen countless instances of "insignificant" edits (i.e. no major content, just adjustments like renaming "iPhone 4 GSM" to "iPhone3,1"), and there were a lot of complaints about this. We're not going down that road again. The main reason other wikis don't have a rule like this is probably because other wikis never deal with floods of edits just to rename one thing on such a frequent basis. On this wiki, a humongous change like this seems to happen every (other) year. (Why? This shouldn't be the case.) The rule stays, but it's open for amendments— we can increase the limit count, for example. --Dialexio (talk) 21:16, 22 March 2017 (UTC)

I do think we should increase it. I'd propose either 75 or 100 daily edits and 30 major/minor (30 of each that is) per hour. Especially when we have a new firmware release, it is easy to go over 20 edits and if quick enough, could be done within an hour so I do think we should allow for more. I am with Spydar007 partly though as, although I can see why the rule was useful, we don't get enough editors to really cause an issue with this. If that changed, then we could review it. However, it isn't a make or break for me but I do think removing it would be a fairly good idea due to how few people edit this wiki now. I've also always thought that it would be better to fill Recent Changes on one day with big edits like that are currently taking place and then it be over, than do less edits that take a lot longer. --iAdam1n (talk) 10:22, 23 March 2017 (UTC)

If that's the reason the rule was put in place, then it should definitely be removed. This rule does not prevent those edits from being made; it simply prevents the number of edits that can be made in a given time. With the same few editors, no one is going to be renaming "iPhone 4 GSM" to "iPhone3,1", or anything like that. And again, this rule doesn't prevent those edits from being made. I've never seen a large amount of these "insignificant" edits being made in any of the time I have had an account on this wiki. I'd say this is to do with the changing userbase of the wiki, and not anything else.

If you absolutely insist that the rule is kept, then it should be changed to allow 50 edits per hour. No daily limits. This allows for plenty of cleanup to be made. Of course, if we start to see people making silly changes, then a nice message on the user's talk page usually suffices, and a general discussion about why the user feels that page or file should be changed or renamed, and not the creation of a rule to allow you to block the user. This rule was added (and from what I can see, with no discussion) on December 12, 2011‎. I can see no violations of this rule in silly page moves before this date. I simply do not see a need for this rule, and I feel like it hinders the amount of actually constructive edits to the wiki. — Spydar007 (Talk) 11:07, 23 March 2017 (UTC)

There absolutely was a discussion. It's not meant to prevent these types of changes, as they can be necessary; it's meant to keep the list of changes accessible/readable, since an edit that's either questionable or notable (e.g. information about a new OTA package format) can easily be buried among 94 edits of merely renaming "iPod touch 4G" into "iPod touch (4th generation)." That said, taking the feedback into account, I think raising the limits to 50 major/50 minor edits per hour, with a daily limit of 150 edits would make a fair compromise. (Not having the daily limit would mean that you can actually make up all of the last 2,400 edits in one day. Uh… No.) --Dialexio (talk) 16:17, 23 March 2017 (UTC)

That limit would be awesome. I really like that idea of 50 major/50 minor edits per hour and 150 daily limit. --iAdam1n (talk) 16:35, 23 March 2017 (UTC)

---

Okay, I think Axi0mX's contributions highlighted something about this rule: if someone dumps a bunch useful information across numerous pages, it can very easily affect them. Contributions like these were not the intended target of the rule, and people shouldn't be punished for trying to share such information. However, we do need a system in place to limit insignificant changes— we do not, and should not, need to rename a key page every two years. I want to propose changing this to allow informative edits, such as the keys Axi0mX shared, while imposing a limit on inconsequential changes.

The following blurb reflects the changes I wish to make, and will be edited as suggestions are implemented. (Emphasis is added to highlight changes, and will not be part of the rule.)

From time to time, the format of pages on The iPhone Wiki may require changes. For example, we determined it was necessary to name device pages by their internal identifier (e.g. N72AP), and use the model identifier in firmware key pages (e.g. Sugar Bowl 5F138 (iPod2,1)). However, making a lot of editsformat changes like this causes the Recent changes to be filled up, as numerous pages must be edited or renamed to follow the new format. In addition to annoying those that subscribe to the Recent changes feed (via Atom or Twitter), this hindersBy filling the Recent changes feed with insignificant changes, everyone's ability to discover new information and track down any malicious changesedits is unnecessarily hindered.

Therefore, for every hour (resetting at :00), you may only make 50 major edits and 50 minor edits. Do not abuse the ability to mark edits as minor to perform additional edits— if your non-minor edits look considerably similar to minor edits you made in the same hour (or vice-versa), this may be considered abuseup to 50 format changes. In addition, you may make no more than 150 edits pertaining to such format changes per day (resetting at midnight UTC). Any unused number of edits pertaining to format changes will not "roll over" to the next hour or day. Avoid "clumping" your edits.Any such edits should not be "clumped" together. (e.g.- Do not make 45 edits for format changes at 01:58, and then another 45 at 02:01.) Temporary exemptions can be made at the discretion of administrators and/or the community. Enforcement of this rule is otherwise subject to the administrators' discretion.

This is a rough proposal, but I think this is going in the right direction. Are there any objections/suggestions? --Dialexio (talk) 02:11, 21 July 2017 (UTC)

Sounds ok to me. I'd probably add firmware updates to the list of informative edits as they are pretty important. The only issue I can see with this is there will be a load of things not covered and could be confusing. I'm thinking maybe we could remove the rule altogether and if we get into an issue in future, add it back for certain things, such as key page template changes, although I hope we never do that again. If we must keep the rule, then I'd say keep it only for format changes. --iAdam1n (talk) 12:02, 21 July 2017 (UTC)

Good point. Although I tried to provide examples of what should/should not be considered "informative," it can seem confusing. Considering that this rule was created pretty much solely because of the constant format changes, targeting those specifically should be fine. Unless someone has a second opinion, I'll revise the proposal tonight. (I don't have time right now to work on the text. I swear it's not because of Splatoon 2... Yet.) --Dialexio (talk) 16:13, 21 July 2017 (UTC)

Wiki Logo Update 2017

I think it's time we update the logo in the top left corner again. iPhone 4S and iOS 5 are so 2011. And that font definitely isn't San Francisco. I'll see if I can get something worked out. --5urd (talk) 05:48, 20 September 2017 (UTC)

I believe Dialexio has already been working on this, see his Twitter for examples. — Spydar007 (Talk) 06:27, 20 September 2017 (UTC)

Yup, I've been working on this for a few days now. As of now, this is what I have so far. I was actually planning to make a topic about this today, but I guess I got beaten to the punch. :P --Dialexio (talk) 17:06, 20 September 2017 (UTC)

I was thinking something with iPhone X, too. But I think it should face the other way. Unless there's two phones back to back, having one face left looks weird IMHO. --5urd (talk) 21:41, 20 September 2017 (UTC)

I couldn't find any (clean) images from Apple that had the iPhone X facing right. I see no issue with the direction that the phone faces, though I suppose a right-facing one would've been a cleaner replacement for the current logo. --Dialexio (talk) 00:18, 21 September 2017 (UTC)

On apple.com/iphone, there's a big image of iPhone X: iphone_x_large.jpg (981x206). There's also large.mp4 (extracted image - 1024x246). Would either of those work? --5urd (talk) 00:44, 21 September 2017 (UTC)

Honestly, I think using a landscape iPhone would look even weirder than a portrait-oriented iPhone facing left. (There really isn't anything wrong with the latter.) Aside from taking or viewing photos/videos (...okay, games too, but those aren't exactly included from the get-go), iPhones aren't depicted in landscape. I did make an attempt to see what I can do with the first image, but when I tried resizing the first image to fit the logo's 150x150 size, I felt that it became somewhat difficult to identify as an iPhone. It almost looks like it's just a random bar of colors. Considering the dimensions for the second, I imagine that it would have a similar result. --Dialexio (talk) 03:28, 21 September 2017 (UTC)

Well you would rotate them 90° clockwise; I meant to specify that, but failed to do so. Anyways, considering the fact that iPhones have gotten bigger, there's not much we can do with only 150×150 pixels. In fact, MediaWiki recommends no bigger than 135×135. That documentation page does note, however, that we can use a bigger logo with some changes to the CSS. --5urd (talk) 00:51, 22 September 2017 (UTC)

Okay, I just tried rotating it, and I don't like the result at all— it seems off-center since the iPhone image is thinner. For both my version and the suggested swap, I made minor edits to the gradient color and switched to SF Text instead of SF Display. (I put together a comparison on imgur.) I'm sticking with the iPhone X image I originally used for my spin on a new logo. --Dialexio (talk) 03:56, 22 September 2017 (UTC)

Well, the current logo has the iPhone at about the same angle as the second one. I think it only looks weird because it's too far to the left. I do prefer the angle of the first one (your original idea). However, I don't like the left facing direction; We do work in a left-to-right language. I do think, though, that a render of the lock screen is bad. Maybe I just prefer the current logo's use of the home screen because it adds color? I'm not particularly a fan of that wallpaper, but that's just me. I wonder if it would be possible to take all the 3D renders of iPhone X from Apple and build our own 3D model that could be positioned how we want it. I'll try that. In the meantime, I found this: design_expression_large.jpg --5urd (talk) 23:15, 22 September 2017 (UTC)

The left-to-right argument doesn't make sense to me; it's not like I wrote the words backwards or aligned it like it's a right-to-left language. Many Western brands do have an icon/glyph/whatever to the left of the text— Crunchyroll, Dropbox, Microsoft, Seagate, and YouTube all do that. (Of course, some brands like American Airlines and Chase have theirs on the right.) I don't think an image with the Lock screen is bad, but the wallpaper Apple chose for their iPhone X photos is rather... loud. The image I picked would probably look better if the colors weren't so bold. (Don't get me wrong though— I don't mind using a different iPhone X image or swapping the text and picture around, but I couldn't find any iPhone X images that look or fit better, except maybe a shot of the front without any perspective.) --Dialexio (talk) 03:21, 23 September 2017 (UTC)