Last Friday, thousands of owners of Samsung Blu Ray players found that their home entertainment devices would no longer boot up. While devices getting stuck in a power-cycling loop is not uncommon, this case stands out as it affected a huge range of devices all at the same time. Samsung’s support forum paints a bleak picture, with one thread on the issue stretching to 177 pages in just a week.
So what is going on, and what can be done to fix the problem? There’s a lot of conflicting information on that. Some people’s gear has started working again, others have not and there are reports of customers being told to seek in-person repair service. Let’s dive in with some wild speculation on the problem and circle back by commiserating about the woes of web-connected appliances.
[Wladimir Palant] seems to be on a one man crusade against security problems in security software. The name may not be immediately recognizable, but among his other infamies is originating Adblock Plus, which we have a love-hate relationship with. (Look, surf the net with an adblocker, but disable it for sites you trust and want to support, like HaD).
This week, he announced a rather serious flaw in the Bitdefender. The disclosure starts off with high praise for the Bitdefender: “security-wise Bitdefender Antivirus is one of the best antivirus products I’ve seen so far….” Even with that said, the vulnerability he found is a serious one. A malicious website can trigger the execution of arbitrary applications. The problem was fixed in an update released on the 22nd.
Image by Wladimir Palant, CC BY-SA 4.0
The vulnerability is interesting. First, Bitdefender uses an API that was added to web browsers specifically to enable security software to work without performing man-in-the-middle decryption of HTTPS connections. When a problem is detected, Bitdefender replaces the potentially malicious page with it’s own error message.
Because of the way this is implemented, the browser sees this error message as being the legitimate contents of the requested site. Were this a static page, it wouldn’t be a problem. However, Bitdefender provides an option to load the requested page anyway, and does this by embedding tokens in that error page. When a user pushes the button to load the page, Bitdefender sees the matching tokens in the outgoing request, and allows the page. Continue reading “This Week In Security: Bitdefender, Ripple20, Starbucks, And Pwned Passwords”→
In the connected age, every day it appears privacy is becoming more and more of an idealistic fantasy as opposed to a basic human right. In our latest privacy debate per [TechCrunch], apparently the FBI is taking some shots at Apple.
You may find it somewhat interesting that the author of the news piece appears to be more upset with the FBI for cracking the phone than at Apple (and by extension other tech companies) for making phones that are crackable to begin with.
A large part of fighting against the SARS-CoV-2 pandemic is the practice of contact tracing, where the whereabouts of an infected person can be traced and anyone who has been in contact with that person over the past days tested for COVID-19. While smartphone apps have been a popular choice for this kind of tracing, they come with a range of limitations, which is what the TraceTogether hardware token seeks to circumvent. Now [Sean “Xobs” Cross] has taken a look at the hardware that will be inside the token once it launches.
The Simmel COVID-19 contact tracer.
Recently, [Sean] along with [Andrew “bunnie” Huang] and a few others were asked by GovTech Singapore to review their TraceTogether hardware token proposal. At its core it’s similar to the Simmel contact tracing solution – on which both are also working – with contacts stored locally in the device, Bluetooth communication, and a runtime of a few months or longer on the non-rechargeable batteries.
The tracing protocol used is BlueTrace, which is an open application protocol aimed at digital contact tracing. It was developed by the Singaporean government, initially for use with their TraceTogether mobile app.
This smartphone app showed a number of issues. First is that Apple does not allow for iOS apps to use Bluetooth in the background, requiring the app to be active in the foreground to be useful. Apple has its own tracing protocol, but it does not cover the requirements for building a full contact graph, as [Andrew] covers in more detail. Finally, the app in general is not useful to those who do not have a recent (compatible) smartphone, or who do not have a smartphone at all.
A lot of the challenges in developing these devices lie in making them low-power, while still having the Bluetooth transceiver active often enough to be useful, as well as having enough space to store interactions and the temporary tokens that are used in the tracing protocol. As Simmel and the TraceTogether tokens become available over the coming months, it will be interesting to see how well these predictions worked out.
A process design kit (PDK) is a by now fairly standard part of any transformation of a new chip design into silicon. A PDK describes how a design maps to a foundry’s tools, which itself are described by a DRM, or design rule manual. The FOSSi foundation now reports on a new, open PDK project launched by Google and SkyWater Technology. Although the OpenPDK project has been around for a while, it is a closed and highly proprietary system, aimed at manufacturers and foundries.
The SkyWater Open Source PDK on Github is listed as a collaboration between Google and SkyWater Technology Foundry to provide a fully open source PDK and related sources. This so that one can create manufacturable designs at the SkyWater foundry, that target the 130 nm node. Open tools here should mean a far lower cost of entry than is usually the case.
Although a quite old process node at this point (~19 years), it should nevertheless still be quite useful for a range of applications, especially those that merge digital and analog circuitry. SkyWater lists their SKY130 node technology stack as:
Support for internal 1.8V with 5.0V I/Os (operable at 2.5V)
1 level of local interconnect
5 levels of metal
Inductor-capable
High sheet rho poly resistor
Optional MiM capacitors
Includes SONOS shrunken cell
Supports 10V regulated supply
HV extended-drain NMOS and PMOS
It should be noted that use of this open source PDK is deemed experimental at this point in time, and should not be used for any commercial or otherwise sensitive applications.
In its place will be Apple’s own custom silicon, based on 64-bit ARM architecture. Apple are by no means the first to try and bring ARM chips to bear for general purpose computing, but can they succeed where others have failed?
Fresh from ETH Zurich comes the new Silq programming language. They also have submitted a paper to the PLDI 2020 conference on why they feel that it is the best quantum programming language so far. Although it may be not common knowledge, the lack of usable general purpose quantum computers has not kept multiple teams from developing programming languages for such computer systems.
Microsoft’s Q# is a strong contender in this space, along with the older QCL language. The claims by the Silq team on exactly why their language is better appear to come down to it being ‘more high level’, and by supporting automatic (and safe) uncomputation. While the ‘high level’ aspect is suspect since Q# is most decidedly a high-level programming language, their uncomputation claim does at least have some merit.
Quantum algorithm with uncompute step.
Uncomputation is a concept in quantum programming, where one occasionally has to remove a few intermediate objects from the current state because they may cause quantum interference that would affect the resulting output. Normally, one would save the intermediate result to a register for this, then reset the state and continue. Which parts of the state to keep and what to uncompute is however not easily determined, as a quick glance at related answers over at the Quantum Computing StackExchange and Theoretical Computer Science might reveal.
The main question thus appears the validity of this claim about Silq being able to automatically determine what ‘garbage’ can be safely uncomputed, and what should be part of the quantum interference. We have all seen with languages like Java and C# how even with traditional computing something as simple as garbage collecting can go horribly wrong. Maybe we shouldn’t count our quantum chickens yet until this particular waveform has fully collapsed.
