Winner Congratulations to team DSEC on winning the SCORE 2023 competition for the project DSEC: A Data Analyzer tool for ensuring secure software development life-cycle. See here for all finalists.
Members of the DSEC team are:
André Schjøth, Politecnico di Milano
Giovanni Demasi, Politecnico di Milano
Lorenzo Poletti, Politecnico di Milano
Lucija Strejček, University of Zagreb
Jan Rocek, University of Zagreb
Kristian Djaković, University of Zagreb
The SCORE Contest is aimed at promoting and fostering software engineering in universities worldwide. Student teams from all over the world participate in a competition for students from undergraduate to master’s level. Each team will develop a software project chosen from a list of projects proposed and sponsored by program committee members. The final deliverable is a report and an accompanying executable system. The evaluation will be based on the quality of all aspects of the software engineering process followed, as well as the resulting system.
In order to accommodate a wide range of academic calendars, the SCORE 2023 Contest will run from April 2022 to March 2023. Finalist teams will be invited to ICSE 2023 in Melbourne, Australia.
Team Registration: Please, fill out this form by December 1, 2022.
Summary report submission: Please submit the summary report via HotCRP by Jan 12, 2023.
Thu 18 MayDisplayed time zone: Hobart change
11:00 - 12:30 | |||
11:00 5mDay opening | SCORE 2023 Introduction SCORE 2023 | ||
11:05 15mTalk | DSEC: A Data Analyzer tool for ensuring secure software development life-cycle SCORE 2023 | ||
11:20 15mTalk | PDFL - PDF Legacy, Smart Paper Reader SCORE 2023 Matteo Visotto Politecnico di Milano, Paolo Corsa , Ettore Zamponi Politecnico di Milano, Salvatore Gabriele Karra Politecnico di Milano, Tonio Ercegović , Nina Gnjidić , Dario Mesic | ||
11:35 15mTalk | CodeDefenders: RoboTournament - CodeBenders team SCORE 2023 | ||
11:50 15mTalk | PrivTAP: Privacy-preserving Trigger-action IoT Platform SCORE 2023 Enna Basic , Michele Benedetti Mälardalen University, Leonardo Panseri Politecnico di Milano, Ivan Radonjic Mälardalen University, Emanuele Santoro Politecnico di Milano, Alessandro Sassi , Lorenzo Maria Vaccarini | ||
12:05 25mMeeting | (Private) SCORE PC meeting SCORE 2023 | ||
Accepted Papers
Call for Participation
The seventh edition of the Student Contest on Software Engineering (SCORE) is part of the 45th International Conference on Software Engineering (ICSE 2023).
SCORE is a worldwide competition for undergraduate and master’s level students. It emphasizes the engineering aspects of software development, not limited to programming. Student teams participating in the contest will complete a full-lifecycle software project on a selected project topic.
To take part in the competition, teams must register and follow the contest rules as outlined below. Upon completion of their work, teams will submit an initial project report (via HotCRP; then, qualifying teams will submit full software products covering the whole software development process. After a careful evaluation carried out by the SCORE Program Committee, a limited number (about 3 to 5 – the exact number will be advertised later) of finalist teams will be invited to the final project presentation during ICSE 2023 and will receive their awards at the end of the conference.
Please consider promoting the SCORE contest to your students and colleagues. A flyer is available for download. Also, be sure to pay attention to the SCORE timeline and important dates.
Overview
Between March and November 2022, teams of 3-6 students can enter SCORE 2023: they select a project topic among those offered, and register using this form. Their goal is to undertake a full-fledged software engineering project that adheres to the chosen topic description and encompasses all aspects of the engineering process, including planning, requirements, design, implementation, and testing.
Following the best software engineering practices, teams document the process and its outcomes using formal and informal notations, configuration management tools, and process-specific techniques. They collect all artifacts and documentation and produce a detailed project report. By the 12 January 2023 deadline, teams submit a summary report not exceeding 20 pages via HotCRP, which gives a self-contained summary of their project development.
Based on the summary reports, the SCORE Program Committee selects a number of semi-finalist teams to submit their complete project reports and artifacts by the 2 March 2023 deadline. After evaluating the complete reports and artifacts of semi-finalist teams, the SCORE Program Committee selects a limited number of finalist teams by the 24 March 2023 deadline and invites them to present their projects during ICSE 2023 (which might be held virtually).
Awards
An overall SCORE 2023 winner will be selected by the Program Committee after presentations at the ICSE 2023 conference. All finalists will be recognized at the conference. The winning team will receive an award certificate in digital format.
Contest Rules
(see also: FAQ)
Project topics must be selected from the official SCORE projects list. Self-defined or any other project topic will not be accepted for SCORE submission. Always remember that the main focus of the participants should be to produce state-of-the-art software by following a sound software engineering process.
Each project topic description lists one or more reference persons in the SCORE Program Committee who may be contacted with questions regarding the project topic that are not covered in its description. Interactions with a project’s reference persons are limited to teams that have officially registered for that project topic and are subject to restrictions and rules specified in the project description.
Team Registration
Teams that wish to participate in SCORE must register using this form. Registration must be done no later than 1 December 2022.
Team Composition
Participating teams must be composed exclusively of students, at the undergraduate and at the graduate (Master’s) level. Every team must have no less than 3 members. Teams are strongly advised to have no more than 6 members. Teams may be formed and projects may be developed as part of a software engineering course. Also, teams can be composed of students from different institutions and, in general, teams can work and collaborate from a distance [see For Software Engineering Instructors].
Every team must designate 2 contact persons, to whom communications and inquiries will be addressed. One contact person must be a member of the team; the other may be another team member or a faculty person who is supervising the students (for example if the project is carried out in the context of a software engineering course). However, the faculty person cannot actively participate in the development of the project with the supervised team.
Project Development
Since SCORE is a Software Engineering contest, participating teams are required to undertake, at least partially, all aspects of the engineering process, including planning, requirements, design, implementation, and testing. Requirements should be described adequately (by traditional means or perhaps by means of user stories, use cases, and scenarios). The outcome of the design phase should be a document that at least describes the architecture model. Implementation must follow the principles of modern software engineering (this includes proper source code documentation). Testing must include unit testing, and possibly integration and acceptance testing.
Projects may focus on some aspects of the process or system and devote more time and space to them in their reports, provided that no aspect is completely neglected, and all are documented. Project documentation must be entirely in English. Reports written in any other language will not be considered or evaluated.
Software Engineering Process
Teams are free to choose their own development approach and to organize their process accordingly. However, they should provide adequate process documentation to show they defined and followed the chosen process.
The use of basic software engineering tools such as source code repositories with version control management, build systems, and testing frameworks is expected; the documented, proper use of more advanced tools will be favorably valued in project reviews. Continuous integration systems, static analysis tools, advanced testing and coverage tools, formal methods, and other types of methods and tools can strengthen teams’ software engineering methodology and ultimately aid them in producing a better product.
The appropriate use of diagrams in project documentation is expected. Different projects will have different needs, so there are no fixed requirements, but both formal and informal diagrams can aid in understanding and documenting both requirements and design.
Conflicts of Interest
Program Committee members will not evaluate projects developed by teams including members who are or have been affiliated with the PC members’ institution at any time (regardless of which project is developed by the teams). As for conflict timespan, ACM conflict of interest rules generally apply to the SCORE contest.
Licenses and copyright Issues
Unless exceptions are explicitly stated in advance, all artifacts produced by the teams will be treated confidentially by the PC during the evaluation phase. All projects will be released under a FLOSS license, which is indicated by the project sponsor in their detailed proposal. If the suggested license cannot be accepted (e.g., due to institution requirements), teams are requested to reach out to the sponsor before submitting the initial report, to motivate and negotiate an alternative license.
Paid Work
SCORE 2023 projects cannot be performed as part of paid industrial work. Team members may be supported in their studies by assistantships, scholarships, fellowships, or the like, but duties associated with the support must not be tied to participation in the SCORE project.
Submission and Evaluation of Deliverables
Abstract and Summary Report
To take part in the SCORE contest, teams must register before the 1 December 2022 deadline. Then, before the 12 January 2023 deadline, they must submit a report of no more than 20 pages via HotCRP. Such a report must be formatted single-column with no less than an 11pt body font. The report should describe the various artifacts produced during the development.
The report must include: documentation of the software engineering process; overview of the requirements; overview of the design, including trade-offs and choices; description of the implementation, including platform choices, team assignments, design changes; description of verification and validation activities and outcomes; description and evidence of implementation operation; and a post-mortem analysis with project reflection, lessons learned, and other important non-product outcomes of the project.
It is expected that full project documentation will not fit into the 20-page report, thus you will need to choose your material and craft your report carefully. It would be good to include evidence of project progress such as graphs or analyses of repository activity, growth of user story base, project velocity graphs over iterations, and other such data analysis that shows project progress throughout its timeline and equitable team participation.
Each submitted report will be evaluated by at least 2 members of the SCORE Program Committee. The evaluation will be based on standard quality criteria for software development.
Final Deliverable
From the report evaluations, a select number of teams will be asked to submit final, full deliverables before the 2 March 2023 deadline. There is no fixed cutoff on the number of teams selected; rather, it will depend on the number of high-quality submissions that are received.
The final deliverable requires you to update your final report and upload it again to HotCRP – updating the previous submission. The final report must include a new section titled "Demo” with a link to access the source code and a link to the Demo to show a fully functioning project. For web applications, it is sufficient to provide an URL pointing to a publicly accessible server where the project has been fully deployed. For other types of projects, we recommend providing a fully functioning project installation in a self-contained Docker container or VirtualBox virtual machine (VM) image. The project documentation should include instructions on how to install and run the application. For projects that involve mobile or other special platforms, for example, the virtual machine can be based on a simulator of the platform running the developed application. Other alternatives are welcome as long as they make the life of Program Committee members easy when it comes to installing and running the projects.
Regardless of the choice, teams are encouraged, wherever possible, to use non-commercial platforms for their installation. If a project depends on commercial software, it must be properly licensed.
The final deliverable (regardless of the chosen format) must include or make available to the Program Committee the implementation code and other development outcomes (work products such as specifications, tests, verification experiments, and so on). The teams are responsible to deliver all the material that is necessary to run and fully evaluate their product (this will include any non-standard, non-free, or non-publicly available development tools, libraries, run-time environments, and so on).
Failing to comply with all these requirements is expected to have a large, negative impact on the evaluation of the project. The evaluation will be based on the quality of all aspects of the project (process followed, development outcomes, and so on).
The Program Committee will then select a small number of overall SCORE finalists based on the final deliverables. Depending on the final budget made available, one or more representatives from these teams will be invited to present their projects at the ICSE 2023 conference (see below for more).
Financial Support to Finalists
We anticipate that the ICSE 2023 conference will provide a financial award to help offset travel expenses to one member per team for finalist teams. Free registration to the main conference will be offered to a limited number of members of the finalist teams. Anyway, full and final details about financial support to finalist teams will be posted when the overall conference budget is finalized.
If ICSE 2023 is to go virtual due to the COVID-19 pandemic, finalist teams will present their work remotely. Therefore, travel compensations are not needed anymore. We reserve to post full and final details about any form of prizes or awards for the finalists and/or winning team.
Important Dates
- SCORE Registration of Project Teams Open: From 4 May 2022
- SCORE Submissions of Summary Reports Open: From 6 June 2022
- SCORE Teams Registration Deadline: 1st December 2022
- SCORE Summary Report Submission Deadline: 12 January 2023
- SCORE Notification of Semi-Finalists: 10 February 2023
- SCORE Submission of Full Deliverables Deadline [Semi-Finalists Only]: 2 March 2023
- SCORE Notification of Finalists Invited to ICSE 2023: 24 March 2023
- SCORE Final Presentation [Finalists Only]: 14-20 May 2023
Contact Details
Should you need further clarification, do not hesitate to contact the SCORE 2023 co-chairs:
- Luís Cruz – l.cruz@tudelft.nl
Delft University of Technology, The Netherlands - Xiaoning Du – xiaoning.du@monash.edu
Monash University, Australia - Mattia Fazzini - mfazzini@umn.edu
University of Minnesota, United States
FAQ
Ownership
Q) Upon submission of the project who will have copyright/ownership over the project?
Student teams own the work that they do unless the students’ institution(s) have other rules that supersede these rights.
Team composition
Q) How large must a team participating in SCORE be?
The minimum number of people in a team is 3, in order to guarantee that project development involves real teamwork. The maximum number of people in a team is 6.
Q) Do I have to be a student to take part in SCORE? What kind of student?
Yes, you must be a full-time student, and you must provide proof of this fact when submitting your project. We allow both undergraduate and Master’s students, but no Ph.D. students. Teams can mix undergraduate and graduate students.
Q) Why not Ph.D. students?
It is a matter of fairness, as Ph.D. students are usually well versed in software engineering theory and practice, having studied the subject in great depth both in classes and during their research activity, which gives them an unfair advantage over much less experienced competitors.
Q) I am currently a student at the Master’s level, but I will receive my degree in the year 2022, then I will start a Ph.D. program. Can I still be part of a team participating in SCORE?
It depends on when the summary report is submitted. We will check the status of the members of a participating team at the time of the submission of the summary report (which can be any time between July 2022 and January 2023). If you are still a student at the undergraduate/Master’s level at that time, then you (and your team) will be allowed to participate in SCORE 2023.
Q) I am currently a student at the undergraduate/Master’s level, but I will graduate in the year 2022, and then I will start working for a company. Can I still be part of a team participating in SCORE?
It depends on when the summary report is submitted. We will check the status of the members of a participating team at the time of the submission of the summary report (which can be any time between July 2022 and January 2023). If you are still a student at the undergraduate/Master’s level at that time, then you (and your team) will be allowed to participate in SCORE 2023.
Q) Can members of the same team come from different institutions or countries?
Yes, they can. Diverse teams are very welcome, although SCORE does not provide any mechanism to form or facilitate the interaction in such teams, so the team formation and management is up to the team members themselves.
Q) Is it required for each team to have a reference faculty member? Is it advised? What is a faculty advisor’s role?
There is no mandatory requirement on having a reference faculty member, although it is fine (and probably useful) if teams have one. It has to be understood that the faculty referent must be at most a general advisor, and must not participate actively in the development of the project by the team.
Q) What happens if a team composition changes after the team has registered?
A limited amount of changes in the team composition are allowed even after registration. For instance, the team may grow in size, or one person may be replaced. The contact person, however, cannot be changed. We also require that changes in team composition be promptly reported by updating the registration data in HotCRP.
On the synergy between SCORE and Software Engineering courses
See also the page dedicated to this topic.
Q) I teach a Software Engineering course at my University. Can my students develop SCORE projects within the course framework and timeline?
Absolutely! This is allowed and encouraged, is an excellent way to reach a large base of potential (and talented!) participants, and it is a great way for instructors to provide challenging projects to their students.
Q) How can I accommodate SCORE within my course schedule?
The SCORE timeline is designed to allow a project to be undertaken during 2022, to match well with most university course schedules. The target SCORE project size is approximately a standard one-term team project.
On project submission and evaluation
Q) How is the evaluation process managed?
The evaluation is a two-phase process. First, every team delivers a summary report (the deadline is 12 January 2023, but reports can be delivered earlier; see the CfP for suggestions on the production of the report). The report will be evaluated by members of SCORE’s Program Committee. Based on this first evaluation, a subset of the teams will be invited to submit full project documentation (see here), which will be used by the PC to select the finalists (to be invited to ICSE) and the winners (from among the invited finalists). The final evaluation may also depend on the teams’ oral presentations given at ICSE: suggestions will be given to the finalists on how to organize their presentations.
Q) How are project submissions evaluated?
Since the level of complexity varies across proposals, these are the broad areas that will be considered in the assessment. For finalist projects-only, the working software that can be demoed will be the key deliverable and will be judged by the PC, client, and chairs in relation to how well the software meets the requirements. Requirements: The quality of the software requirements and the relevant documentation in terms of clarity, consistency, comprehensiveness. Design: The quality of design of the system including an appropriate level of detail. Implementation (for finalist projects): Evidence showing that the system is functional and about decisions related to implementation, decisions, and technologies used. Collaboration: Clear evidence of how the team collaborates internally and with the client to develop the software system. Verification/Validation: The effectiveness and rigor of the software quality assurance process and outcomes.
Q ) Under what license will the project have to be released?
SCORE 2023 will not force a specific license, which instead will be indicated by each sponsor in their project proposal. Still, (a) by default, we recommend the GPL of the LGPL licenses, which will grant reviewers access to the code for evaluation (see below) while preventing at the same time anyone to close-source and become proprietary of the project code afterward; (b) should their institution have different requirements, student teams and instructors are invited to reach out to the sponsors to identify an alternative license – in this case, we request teams to add the written agreement (even an email will suffice) to the project report when submitting it for evaluation. If you need more information about different FLOSS licenses, see here and here.
Q ) Should the project source code be accessible?
Yes, regardless of the final license of the project, teams passing the first evaluation will be required to make the source code available to PC members as part of the full documentation. For this reason, we require teams to share their project on a code hosting platform such as GitHub or GitLab. All the material will be treated confidentially by the SCORE organizers and PC members.
Q) Can my team send the application code/test results/verification results, instead of (or in addition to) a 20-page document, as the summary report?
No, you will be allowed to submit only the 20-page report. You will be asked for additional, more in-depth information and deliverables for your project only if you are selected as a semi-finalist for the second phase of the evaluation.
Q) Does this mean that we can delay doing the implementation until we are selected as semi-finalists for the second phase of the evaluation process?
No. Given the short time (about a month and a half, from mid-January to March 2023) between the summary report and the final deliverable, it is expected that your project will be completed in all its aspects and fully documented by the time you submit the summary report. The report also documents your development process, which must have actually occurred.
Q) We are registered for the SCORE contest; do we have to wait until January 2023 to submit our summary report, even if we have finished it well in advance?
No, you don’t have to wait until January 2023 to submit the project’s summary report. If your project is completed earlier than the submission deadline, you can submit it when you are finished. When you are ready, please submit via HotCRP.
Q) We have already submitted the summary report for our project, but submissions are still open: can we submit a new version of the report?
Yes, you can modify your submission and send us a new, revised summary report as long as submissions are still open. Only your latest submission will be considered for evaluation (and will have to respect all criteria for eligibility for evaluation, including those on team composition).
Q) We have submitted the summary report well in advance of the closing date for submission: will you evaluate our project and notify us if we have been selected to send the final deliverable before the notification date?
No. To coordinate the program committee (PC) work, to be considerate to the PC members’ own need to schedule their reviewing, and to be sure that all reviews are equitable, all reviewing will take place between the report submission deadline and the notification deadline (10 February 2023).
For SE Instructors
We encourage software engineering instructors to consider advertising SCORE to their students and to use one of SCORE’s project topics for their own software engineering teaching assignments. This can be of great benefit for both students and instructors. Here are a few hints to best exploit the opportunities offered by SCORE.
SCORE projects are challenging and should solve real-life problems, so your students can have a unique learning experience. Typically, SCORE projects can be, but do not have to be, developed during a university software engineering course. In some cases it may happen that only certain parts of a SCORE project can fit with the specific focus of your course; in such cases, we suggest that you invite the best students to form teams and officially enter the SCORE contest as a follow up of their work accomplished during the course.
Administering SCORE projects and supervising SCORE teams is an excellent way to motivate and challenge your best students, as well as to make your own school and courses internationally visible by the quality of their achievements. Similarly, one of SCORE’s main goals is to reach a large base of potential (and talented!) participants.
For Project Sponsors
NOTE: Only SCORE PC members may sponsor a project. This page is for them
We need a good number of projects for teams to choose from! A project sponsor (or proposer) does not need to expect to take on a tremendous burden of work. Yes, you will need to define the project, but you can determine your own level of interaction with teams (even down to none), and we can adjust your reviewing activity to compensate. So, propose a project!
Project Proposal Structure
A project definition needs to have:
- A project short name: try to come up with a catchy, self-explanatory name for your project.
- A short description (abstract) of the idea.
- A longer narrative of the problem that gives enough detail for a team to actually go out and work on the project.
- A scoping statement for the project that helps teams understand what must be, what may be, and what does not need to be part of the project, in order to help them understand what is asked for.
- A statement of any process requirements that teams must follow.
- A statement of any environmental constraints (equipment, external interfaces, or other external constraints) that must be satisfied.
- Any restrictions or requirements on what external software cannot or can be used, including commercial tools, open-source libraries or frameworks, etc.
- The selected license under which the developed project must be released – by default GPL (check the FAQ for more).
- A statement of the level of involvement that you as the project sponsor will undertake; this can be something like “will answer selected questions once per week”; also indicate how to reach out (email, Slack, etc.)
You are encouraged to use this project template. You may also want to look up project descriptions from previous editions of SCORE to get an idea of the variety of aspects that you can cover.
Conflicts and Restrictions
A project sponsor has a conflict with a team if one or more of the team members are students of the same institution as the sponsor during project development or if the sponsor has collaborated with one or more team members in research or other work-related activities during the years 2020 and/or 2021.
Accordingly, a team cannot develop any projects proposed by a sponsor who is in conflict with any members of such a team. The team can still enter SCORE by picking another project topic. In this case, the sponsor will not review the team’s submissions.
Project Proposals
- Clippy: smart PDF reader for better paper reading experience and knowledge mining
- CodeDefenders: RoboTournament
- DLTT: A Toolkit for Testing Deep Learning Software
- DSEC: A Data Analyzer tool for ensuring secure software development life-cycle
- Plagiarism Checker for Assignments in Computer Science Courses
- PrivTAP: Privacy-preserving Trigger-action IoT Platform
- Supporting the Human Value of Universalism via Localisation of Android Apps
Clippy: smart PDF reader for better paper reading experience and knowledge mining
Reading papers is an everyday task for researchers. This project aims to build a smart PDF reader to provide better reading experiences for researchers. This PDF reader should have two key features: First, it should be able to parse the PDF file to extract essential information (such as figures, tables, references, etc.) from the paper. Second, it should be able to mine knowledge from the extracted information to help with paper comprehension and inspire new research ideas.
Sponsors:
- Xiaofei Xie - Singapore Management University, Singapore
- Yuekang Li - Nanyang Technological University, Singapore
- Yun Tang - Nanyang Technological University, Singapore
CodeDefenders: RoboTournament
CodeDefenders is a (Web) game that helps students learn software testing by letting teams of students compete over some code under test (e.g., a Java class): Attackers inject faults into the code under test by mutating it, whereas defenders write unit tests that spot those problems. If a fault escapes testing, attackers earn points; otherwise, defenders do. Currently, CodeDefenders allow (human) players to spontaneously start/join games or requires an admin to manually set up the games and assign players to them. The goal of this project is to extend the CodeDefenders by allowing tournaments and enabling students to compete against bots.
Sponsors:
- Alessio Gambi, IMC University of Applied Sciences Krems & University of Passau
DLTT: A Toolkit for Testing Deep Learning Software
Deep learning (DL) has become a new paradigm for solving many real-world problems due to its astonishing performance in different domains such as image analysis, natural language processing and system security. However, DL has also been shown to be vulnerable to different kinds of “errors” which makes it challenging to develop robust DL software. Therefore, to improve the reliability of DL software, it is crucial to have a systematic platform for automatically testing the robustness of trained DL software. Till now, many robustness testing approaches have been designed to test DL software. In this project, a framework-agnostic DL testing toolkit (DLTT) including 1) test input loading, 2) test case generation, 3) model profiling, 4) test criteria evaluation, and 5) test report generation should be implemented. DLTT can be implemented on a specific mainstream framework, e.g., Tensorflow or PyTorch. Even better, if DLTT can support multiple frameworks, which is however not mandatory.
Sponsors:
- Jingyi Wang, Zhejiang University, China
DSEC: A Data Analyzer tool for ensuring secure software development life-cycle
Data is a critical and differentiating factor for organizations. Government and lawmakers introduced policies and regulations to govern the usage, storage, and processing of this data to safeguard user rights and allow its ethical consumption. Various policies such as GDPR, White House executive order on cybersecurity, zero trust architecture etc. highlight security practices and guidelines to mitigate unauthorized access and storage of PII data. The aim of this project is to help developers to find security hotspots and inconsistencies in different SDLC artifacts to suit the policies governing data.
Sponsors:
- Vikrant Kaulgud, Accenture Labs, Bangalore, India
- Kapil Singi, Accenture Labs, Bangalore, India
Plagiarism Checker for Assignments in Computer Science Courses
In some curricula, students are required to complete a project or answer some open-ended questions. However, some students may cheat by copying former students’ assignments. The goal of the project is to develop a tool to automatically check duplicate assignments. It can help teachers to check whether there is plagiarism in students’ Assignments.
Sponsors:
- Cuiyun Gao, Harbin Institute of Technology
PrivTAP: Privacy-preserving Trigger-action IoT Platform
With the rapid adoption of the Internet of Things (IoT), new technologies such as various IoT application platforms start booming. Trigger-action platforms are one type of such platforms. They allow the users to enable automation by integrating multiple third-party services. A simple automation example is turning on Philips Hue smart light if the user is tagged in a Facebook post. Popular trigger-action platforms include IFTTT, Zapier, and Microsoft Flow. However, these platforms have privacy vulnerabilities due to design flaws, and a recent work [1] specifically targets these issues. One of the main design flaws is that the existing platforms do not allow configuring fine-grained access control for sensitive data. This project aims to develop a trigger-action application platform that provides users with access control over sensitive data when integrating multiple third parties to enable automation.
Sponsors:
- Kulani T. Mahadewa, University of Moratuwa, Sri Lanka
Supporting the Human Value of Universalism via Localisation of Android Apps
Human values are an important aspect of life and should be supported in ubiquitous technologies such as mobile applications (apps). There has been a lot of focus on fixing certain kinds of violations of human values, especially privacy, accessibility, and security while other values such as pleasure, tradition, and universalism have received little focus. Universalism is an important value that aims to promote equality and should be supported in mobile apps. Apps such as the ones based on the Android operating system, run on many devices in many regions. To support internationalisation, localisation and universal reach to most users, these apps should handle text, audio files, numbers, currency, and graphics in ways appropriate to the locales where the app is being used. However, not all apps today support the internationalisation and localisation of their contents. In this project, we aim to provide a toolset that would detect cases when apps do not support the localisation of app contents and provide fixes for these apps.
Sponsors:
- Humphrey Obie, Monash University
- Hourieh Khalajzadeh, Monash University
Previous Events
| Sun 14 - Sat 20 May 2023 Final Presentation [Finalists Only] |
| Mon 3 Apr 2023 Notification of Finalists Invited to ICSE 2023 |
| Thu 2 Mar 2023 Submission of Full Deliverables Deadline [Semi-Finalists Only] |
| Fri 10 Feb 2023 Notification of Semi-Finalists |
| Thu 12 Jan 2023 Summary Report Submission Deadline |
| Thu 1 Dec 2022 Teams Registration Deadline |
| Mon 6 Jun 2022 Submissions of Summary Reports Open |
| Wed 4 May 2022 Registration of Project Teams Open |
