User:Ahm masum/proposal

From Meta, a Wikimedia project coordination wiki

We've already established a conscious, which is why they're called "Mandatory Use User" groups. We don't need to make the same conscious again. So can you tell me, why just 'majority', not 'all' required account holders? Can you, or any advanced permission holder, guarantee us that the current non-enabling state is a 0% security loophole? Are these non-2FA advanced permission holders not a threat to our platform with each passing day?
Yes. I agree. To make a long term effective mass implimentainon we need to rethink/redesigh our current 2FA mathod. We must have to make it as per industry standard, automative as much as possible. We also have to keep in mind that, as a nonprofit charitable organization, we have limited resources. We can't afford to hire too many paid support representatives. -- ~


Enable 180°-360° metadata detection and embed/navigate capabilities in Commons/MediaViewer[edit]



  • Problem: When uploading, Commons can't detect metadata appropriately for the 180°–360° JPEG photos. That’s why we're getting fewer educational 180°-360° panoramas on Commons and fewer Facebook 360°-like photos in articles.
  • Who would benefit: The editor who wants to express their feelings about the surroundings of any place or internal architecture in that article. Instead of showing multiple photos, editors can now show a single 360° photo that contains all of the information they want to show. Readers who like an interactive experience want to feel the surroundings of any place or its internal architecture in any Wiki article they read. It puts the reader or viewer in control of what they want to look at within an image, which is like being in the moment when that particular photograph was captured! They can spin around, look up or down, zoom in, and control where to look—all from their smartphone. All the 2022 released smartphone default camera has a ‘panorama’ option. So, now we can get a huge amount of Commons- and Wikipedia-appropriate educational 180°/360° photos if we implement this community wish.
  • Proposed solution: 1. 1. whitelist (.jps, .mpo). Allow these 2 JPEG-based formats to be uploaded and stored in Commons.

2. 2. Just like animated GIFs, when uploading to Commons, all ‘JPEG’ 180°–360° (assume all 180°+ as 360° automatically) metadata should be detected. They should be extracted with the JPEGMetadataExtractor class and stored in a metadata field (just like Facebook 360).
3. Next, enable Commons/MediaViewer to handle, embed, and navigate 180°–360° photos.

  • More comments: The capability to perform metadata injection manually would be nice. To keep this proposal simple, we shouldn’t mix it with any three-dimensional computer graphics, model objects, stereoscopy, VR, or AR content viewing proposals.
  • Phabricator tickets:
  • Proposer: --MASUM THE GREAT (talk) 00:54, 1 February 2023 (UTC)

____________________________ Enable 180°-360° metadata detection and embed/navigate capabilities in Commons/MediaViewer Problem: When uploading, Commons can't detect metadata appropriately for the 180°–360° JPEG photos. That’s why we're getting fewer educational 180°-360° panoramas on Commons and fewer Facebook 360°-like photos in articles. Who would benefit: The editor who wants to express their feelings about the surroundings of any place or internal architecture in that article. Instead of showing multiple photos, editors can now show a single 360° photo that contains all of the information they want to show. Readers who like an interactive experience want to feel the surroundings of any place or its internal architecture in any Wiki article they read. It puts the reader or viewer in control of what they want to look at within an image, which is like being in the moment when that particular photograph was captured! They can spin around, look up or down, zoom in, and control where to look—all from their smartphone. All the 2022 released smartphone default camera has a ‘panorama’ option. So, now we can get a huge amount of Commons- and Wikipedia-appropriate educational 180°/360° photos if we implement this community wish. Proposed solution: 1. whitelist (.jps, .mpo). Allow these 2 JPEG-based formats to be uploaded and stored in Commons. 2. Just like animated GIFs, when uploading to Commons, all ‘JPEG’ 180°–360° (assume all 180°+ as 360° automatically) metadata should be detected. They should be extracted with the JPEGMetadataExtractor class and stored in a metadata field (just like Facebook 360). 3. Next, enable Commons/MediaViewer to handle, embed, and navigate 180°–360° photos. More comments: The capability to perform metadata injection manually would be nice. To keep this proposal simple, we shouldn’t mix it with any three-dimensional computer graphics, model objects, stereoscopy, VR, or AR content viewing proposals.



the photos that these cameras produce give a fun virtual reality-like interactive experience to the image, where the user can spin around, look up or down, zoom in, and control where to look.

A 360° Photo is a photo that allow us to view more than just a snapshot of a scene . It even let us view the scene from every angle: above, below, behind and next to us & it's also a mainstream media type.

But wiki Articles can't render it & MediaViewer doesn't support it. Images are shown as on the right instead of like this , in the articles.

  • Who would benefit: All the Readers and editors of wikis. 360° photos are effective for showing off vistas, internal architecture and more in a dramatic fashion that replicates the experience of being there.

    Instead of showing 15 photos we could take 1; 360° photo to encapsulate all the information we want to show.It's Also a good way to view panorama photos on mobile devices, where panoramas otherwise are real small.

1. whitelist (.jps, .mpo). Allow these 2 JPEG-based format's to be uploaded & stored in commonce.
2. Just like animated GIF's, when uploading to commonce all 'JPEG' 180/360 (assume all 180+ as 360 autometically) metadata should be detected. They should be extracted with the JPEGMetadataExtractor class and store it in a metadata field (just like facebook 360/google photo).
3. then make commonce/ mediaviewer capable to handle/embade/navigate 180/360 photos.


________ All the 2022 released smartphone default camera has 'panaroma' option. We can get huze amaunt of commonce/wikipedia approprete 180/360 photos if we impliment this community wish. To make this proposal simple, we shouldn't mix it with any three-dimensional computer graphics/model object/Stereoscopy/VR/AR content viewing proposals.

Minimize Wikimedia/Wikipedia's risk by enforcing 2FA on 'Mandatory Use User" groups[edit]

Even though we know, It's extremely important for administrators and editors with advanced permissions to keep their accounts secure, Not everyone in the Mandatory use user groups & SSH key Wikitech users had been enabled 2FA security in their account. If any of these accounts are compromised, it could cause widespread disruption and vandalism in Wikimedia/Wikipedia.
1. Give them a private massage and a month to familiarize themselves with 2FA.
2. Then add them to $wgOATHRequiredForGroups. Prevent them from using their rights until they enable 2FA.

It will minimize Wikimedia/Wikipedia's risk of being compromised.

Proposed solution: Implement T242031. Minimize the situation where people get locked out of their accounts, as much as possible, and automate it. This way Foundation won't be needed any paid staff to act as support representatives. The security team and community tech team should work together on this community wish.

________

Minimize Wikimedia/wikipedia's risk by enforceing 2FA to Mandatory use user groups[edit]

Even though we know, It's extremely important for administrators and editors with advanced permissions to keep their account secure, Not everyone in the Mandatory use user groups & SSH key wikitech users had been enabled 2FA security in their account. If any of these accounts compromise, it could cause a widespread disruption, vandalism in Wikimedia/wikipedia.
1. Give them private massage and a month to familiarise with 2fa.
2. Then Add them to $wgOATHRequiredForGroups. Prevent them from using their rights until they enable 2FA.

It will minimize Wikimedia/wikipedia's risk of being compromised.

Proposed solution: Impliment T242031. minimize the situation where people got locked out of their accounts, as musch as possible & automate it. This way Foundation wont be needad any paid staff to act as support representatives. Security team & coomunity tech team should work togather in this community wishlist.


Give them alart notification, private massage at their Special:Preferences and a month to familiarise with 2fa.
By adding groups to $wgOATHRequiredForGroups, users will be unable to use the rights granted to them by that group until they. This will be displayed privately in Special:Preferences. This will not stop an attacker who compromises an account and then just turns on 2FA to access restricted permissions, rather it's to remind users who are supposed to, that they need to enable 2FA by preventing them from using their rights until they do so. @jrbs, @Reedy, who should sign off on enabling this? And could we get a list of groups it should apply to? Note that we can currently only do it for local groups, not global ones.


We have also provided potential next steps for people who are interested in seeing wider support for 2FA in the future.

Rationale: Currently, 2FA is only available for a small group of editors that have advanced permissions. With this change, all editors would be able to add another layer of security to their accounts. We understand that security is important to people, so we wanted to see if it was possible to fulfill this wish.

When we analyzed this wish, we identified some serious issues.

First, we don’t have the personnel and basic infrastructure to support the wish. if we made this change, we would need support systems in place, in case people got locked out of their accounts. For many companies, they solve this issue by having paid staff to act as support representatives, who may confirm the identity of a user and then unlock their accounts. Unfortunately, the Wikimedia Foundation does not have the resources of such a staff. For this reason, we would need to create an automated solution to handle issues like users being locked out of their accounts.

Conclusion & next steps: Overall, this wish would need to be handled by the Security team. So far, Security folks have shared in T166622 that some steps would need to be taken before any such work could continue.







_______________

  • Problem: Wikipedia Artplace/ Media Viewer can't show 360° paoto as a 360° cause it can't Read/Render necessary 'EXIF metadata tags' from the uploaded photo. When uploading from a 360-ready camera, sometimes 'Metadata Stripping' occurs & there is no 'Exif Editor' in Media Viewer/Commons to do a 'Metadata Injecting'.



Just another animated GIF, showing a concept of usability in wikipedia articles.




Just another animated GIF. Just giving a concept of usability in wikipedia article.
  • Who would benefit:

Editor who want to Express the feeling about the soroundings of any place/ architecture in any article. Instead of showing many photos sometimes he/she can take 1; 360° photo to encapsulate all the information he/she want to show.

Reader who want to feel the soroundings of any Place/ architecture in any Wiki article they read . It puts the reader/viewer in control of what they want to look at within an image, which is like being in the moment when that perticular photograph was captured!

Also, Wikipedia's existing 'panaromic photos' look's very small in mobile devices . adding 360° viewing capability in media viewer will solve this problem .

  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer:

Discussion[edit]